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ABSTRACT 


This CAPSTONE Report documents the Systems Engineering (SE) efforts of 
“Team Marine,” from JAN 2009 to SEP 2009, in developing a recommendation to the US 
Marine Corps Systems Command (MCSC), on the best course of action to ‘Enhance the 
USMC Expeditionary Rifle Squad Communications System.’ 

The squad leader is the cornerstone for USMC tactical operations. Clear, concise, 
accurate and reliable communications to and from the squad leader is the key to squad 
operations, performance and tactical effectiveness. Today’s fielded communications 
system for the squad leader requires the use of two separate radios, each with different 
encryption algorithms, different user interfaces, and different data processing capabilities. 
This primitive design has thrust the squad leader into a complex Human Factors 
environment with disparate components that have not been well engineered or integrated. 

Team Marine applied and tailored the systems engineering (SE) process based on 
NPS course work and professional experience. This SE process enabled the team to 
completely understand and model the current system in terms of architecture, capabilities 
and functions. The process led the team and stakeholders to conclude that an evolutionary 
approach of system integration was preferred over the traditional Manufacturer A vs. 
Manufacturer B run off. 

The team’s recommendation is to pursue an integrated communications system, 
based on existing and emerging components, as the best course of action. The first 
incremental step of the recommendation is to upgrade the existing elements by adding an 
automated communications processor with enhanced human to system interfaces. 
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EXECUTIVE SUMMARY 


The United States Marine Corps (USMC) squad is the cornerstone for tactical 
operations. Clear, concise, accurate and reliable communications to and from the squad 
leader are the key to squad operations, performance, and tactical effectiveness. The 
squad leader is required to receive and accept tasking by higher authorities, request 
additional support as needed by available command elements, and must continually 
update and report unit status to other squad leaders and platoon commanders. All of 
these actions occur while simultaneously; communicating orders and intent, coordinating 
the movement of, and directing the actions of each individual squad member during all 
phases of operations. 

Today’s fielded communications system for the squad leader requires two 
separate radios, each with different encryption algorithms, different user interfaces, and 
different data processing capabilities. The squad members have one type of radio for 
inter-squad communications, while the squad leader has to carry an additional radio to 
communicate with higher echelons. This primitive design has thrust the squad leader into 
a complex Human Factors environment with disparate components that have not been 
well engineered or integrated. The squad leader must now configure, manage and 
communicate on two separate radios, while still being required to deploy and operate 
weapons. 

This poorly integrated system has created an extensive, confusing, and costly 
logistics trail for the USMC to manage, since each radio requires unique power and 
peripheral devices as well as unique training. The lack of an integrated communications 
system affects day to day operations. Since each radio component is a stand-alone 
element, the squad leader’s physical and mental workload is increased by processing data 
between two radios and up to 10 different radio circuits. Each USMC squad deploys 
unique configurations which are unable to communicate with nearby Joint and Coalition 
squads. 
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The Naval Post-graduate School (NPS) Cohort - Systems Engineering (SE) team, 
known as Team Marine, accepted the challenge of ‘Enhancing the USMC Rifle Squad 
Communications System. ’ The challenge originated from discussions with senior 
leadership from Marine Corps Systems Command, and the Program Manager for the 
Marine Expeditionary Rifle Squad program office. To meet the challenge, the team 
applied the NPS SE practices and analysis methods. 

The System Engineering Design Process (SEDP) was used to understand the 
needs of the customer. Non-material alternatives were not considered to be viable to 
solve the capability problem. Four (4) possible material alternative solutions were 
developed to meet the customer requirements. These four alternative solutions were 
derived from the Functional Architecture, Physical Architecture, and Operational 
Architecture. 

Through feasibility screening, modeling and simulation, decision scoring, risk 
analysis and cost analysis the team determined that an evolutionary development effort 
would be the best course of action for MCSC to undertake. 

The team recommends the following course of action (COA): 

1) In the near-term, pursue the Advanced Alternative. This alternative provides 
the squad leader with a fully integrated system comprised of wearable and hand-held sub¬ 
systems. The input devices are internal microphones for voice and touch screens for data 
input. The IISR (AN/PRC-153) provides a short transmission range of less than 3 
kilometers with degraded capability and the AN/PRC-152 provides long transmission 
range that extends to 10 kilometers. This alternative is the best, “bang for the buck” 
integrated solution. As systems mature and technologies become available MCSC should 
be able to evolve the system into the Future Alternative. 

2) PM MERS continue acquisition and development of the Advanced 
Alternative. Include the results of this team’s effort as the foundation for future analysis, 
acquisition, and development. 

3) Migrate to the Future Alternative when feasible. 
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I INTRODUCTION 


A OBJECTIVE 

The project’s Systems Engineering (SE) team targeted a single integrated, 
interoperable, communications system capable of providing transmission relay, voice and 
data networking, and communications processing that can accommodate multiple levels 
of encryption and security among Marine, Joint and Coalition squads. The team’s focus 
and goal is to ‘Enhance the USMC Expeditionary Rifle Squad Communications System.’ 

B BACKGROUND 

1. The United States Marine Corps 

The United States Marine Corps (USMC) uses a multi-tiered and multi-faceted 
command element structure kn own as the Marine Air-Ground Task Force (MAGTF). 
The MAGTF is the premier expeditionary force capable of responding to conflict from 
the ground, air and sea. The MAGTF Expeditionary Force (MEF) is divided into a triad 
of functional command elements under the ultimate control of the MEF Commander. 
The USMC Operational View - 1 (OV-1), (Figure 1 below), depicts the three command 
elements which are the Ground Command Element (GCE), the Aviation Command 
Element (ACE), and the Logistics Command Element (LCE). Each of these functional 
areas is divided by echelon. (MAGTF C2 ICD, 2008) 




Figure 1: MAGTF Operational View 1 (OV-1) (from MAGTF C2 ICD 28FEB2008) 

The MEF command element is at Echelon I, (on the far left), and is depicted as a 
CAPSET I Combat Operations Center (COC). This tiered approach continues across the 
image to the right, down to the CAPSET V components, which includes the USMC 
companies, platoons, squads and teams. 

The MAGTF structure allows the Marines to maximize their tactical advantage 
via a closely integrated air-ground and logistics team. A MAGTF can operate as an 
independent unit, part of a joint or combined task force, as a separate service component 
or as a uni-service force and can deploy by sealift, airlift or both. The MAGTF gives the 
Marine Corps a unique flexibility to respond rapidly to any contingency, anywhere in the 
world. 


2. The Squad 

The tactical operating concept for MERS was developed and defined through a 
series of operational scenarios which examined current and future employment concepts 
for infantry squads. This analysis assisted in identifying critical capability gaps 
associated with the status capabilities provided. The gaps are associated with the lack of 
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a networking capability able to convey Command and Control (C2) and Situational 
Awareness (SA) from higher to lower echelons of command. It was determined that this 
gap was critical to this effort and that the emerging networking solutions have to avoid 
becoming complex while still addressing the critical issues impacting the operations of 
the squad. 

“The Marine Expeditionary Rifle Squad has been the basic building block for all 
Marine Corps operations and concepts since the birth of the Corps. The squad’s 
organization and weapons have changed, but the squad continues to be the tip of the 
spear with the mission to locate, close with and destroy the enemy. ” (MERS CONOPS, 
2009) 


Squad 

Leader 


< - > • ■< -► 


Team Leader 


/t\ /t\ /t\ 





Fire Team 


Figure 2: USMC Squad context 

The basic mission of the MERS is to locate, close with, and destroy the enemy by 
fire and maneuver, or repel the enemy’s assault by fire and close combat (MERS 
CONOPS, 2009). This basic mission never changes. However, the ability to execute the 
mission has grown increasingly complex, due to the introduction of more and more 
sophisticated technologies in a myriad of different operational environments. 

MERS Tactical Operational Concept walked through the gamut of operational 
scenarios faced by the squad in order to examine current and future employment concepts 
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for the infantry squad and to identify any capability gaps. The analysis identified 
Command and Control (C2), Situational Awareness (SA), system networking and its 
ability to become increasingly complex and organic as critical issues impacting the 
operations of the squad. 

“Without the proper communications equipment, the squad will not have the 
capability to seamlessly communicate with joint/combined forces. Situational awareness 
will be lost and combined force effectiveness will be diminished. The potential for 
fratricide also increases. ” (MERS CONOPS, 2009) 

3. Squad Communications 

The expansion of information systems technology has fed the desire for greater 
communications and networking capability for the “last tactical mile” on the battlefield. 
This expansion has lead to the requirement for the ability of a Marine Squad to send and 
receive voice and data to higher, adjacent and subordinate personnel on the battlefield. 
Per the Joint Requirements Oversight Counsel Memorandum (JROCM 071-08), senior 
military leadership has determined that the data at the squad and below is mission 
dependent and may be either classified or unclassified. The JROC set forth the governing 
policy requiring forces operating in the battle space to employ capabilities that protect 
Position, Location Information (PLI). This can be accomplished via two levels of 
classification and encryption. Two-way, aggregate PLI data at the CONFIDENTIAL or 
higher level requires NSA approved Type I encryption methods. One-way, non¬ 
aggregate PLI data below SECRET must be protected at least as Controlled Unclassified 
Information (CUI), using NSA approved Type 2 encryption methods. 

In practice, the Marine Corps has determined that both voice and data 
connectivity from the squad leader to higher echelons will be encrypted as Type 1 data. 
Additionally, the connectivity within the squad (squad leader to squad members) is 
considered CUI and must be encrypted as Type 2 data. 

According to National Information Assurance (2006), a Type I device is an 

cryptographic equipment, assembly or component classified by National Security Agency 

(NSA) for encrypting and decrypting classified and sensitivity national security 

information when appropriately keyed. It is used to protect systems requiring the most 
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stringent protection mechanisms. A Type II devise is a cryptographic piece of 
equipment, assembly or component classified by NS A for encrypting or decrypting 
sensitive national security information when appropriately keyed. Type II classification 
is used to protect systems requiring protecting mechanisms exceeding best commercial 
practices including systems used for protecting unclassified national security information. 

Both Type I & II encryption is developed using NS A business processes and 
contains NSA approved algorithms. 

This decision and doctrinal approach introduces complex requirements that the 
currently fielded communications system cannot easily accommodate. 



Figure 3: Current Squad level communication solution 

The Marine Corps’ currently fielded system was not engineered nor designed to 
address all of the JROCM memorandum requirements. Figure 3 above, identifies the two 
disparate transmission and encryption devices. The dashed - red arrows, on the left side 
of the diagram represent the two-way, classified, Type 1 encrypted data, which is passed 
among squad leaders and up to higher echelon authorities (i.e. platoon leaders). The solid 
- black arrows on the right side of the diagram represent the one way, Type 2, CUI data, 
which is shared among squad members and can be passed onto joint or coalition forces. 
This simple ad-hoc design lacks technical maturity and ignores many human factors. The 
configuration deploys two radios at the squad leader level; one is an AN/PRC-152 (Type 
1 Encryption) for voice only communications between the squad leaders and platoon 
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commander. The other radio is an Interim Intra-Squad Radio (IISR (AN/PRC-153)) 
(Type 2 Encryption) for voice only communications between the squad leader and squad 
members. 

The squad leader now has to carry, configure and operate two physical devices 
with incongruent designs and is still expected to carry out his combat mission, which 
includes engaging enemy forces. 

C SCOPE, BOUNDS, AND ASSUMPTIONS 

After defining the objective, the SE team developed the context diagram below in 
Figure 4. The diagram depicts the context of the system and intended system boundaries 
of this effort. 



Level of Security 

Type 1 

Type 2 

Type 1 or 2 
(Situation dependent) 



Transmission Type 
Voice - User initiated 

Data - C2/SA Device initiated or automated 


Data (one-way) 


Squad Member 
Communications 
Device(s) 


System Boundary 


Figure 4: Communications System Context Diagram 

Figure 4 also shows the information exchange relationships between the squad 
leader, the squad members, other squad leaders (both Joint and Coalition), and higher 


-6- 















command authorities. Physically, the system will be bounded primarily by the 
capabilities, configurations, and interfaces of the communications system for the Marine 
Rifle Squad Leader. The SE team further bounded the problem to concentrate on the 
communication system’s processing capability and the corresponding human factors 
affecting the squad leader. 

The critical assumptions and constraints for the project were determined and 
taken into consideration. These items aided the team in establishing the boundaries and 
scope of the problem description as the team labored toward an understanding of the 
effective need. The following assumptions were defined and used during the early phases 
of the effort: 

■ No overarching requirement documents exist for a squad level 
communications system in the IJSMC. Doctrine continues to mature and 
adapt to emerging technologies and capabilities. The Commandant of the 
Marine Corps published a document (A Concept for Enhanced Company 
Operations, 28 Aug 2008, Department of the Navy, Headquarters U.S. Marine 
Corps) to outline his plan for Enhanced Company Operations (ECO). As 
defined by the Commandant’s concept paper, squad communications systems 
are a subset of ECO. As stated, “Tactical” units must gravitate from push-to- 
talk radio systems to mobile ad-hoc mesh networking.” Marine Corps 
Combat Development Command (MCCDC) is the command assigned the task 
of rewriting and amplifying doctrine. MCCDC is currently taking several 
concept papers (like the ECO) and codifying these concepts into applicable 
doctrine. While this doctrine changes and adapts so do the technologies to 
realize the conceptual constructs and the informing doctrine. 

■ No documented requirement exists for an integrated system capability. The 

Programs of Record (PORs) that acquire and provide communication systems 

to the tactical users are not organized. These same PORs are also not 

mandated to coordinate their systems acquisition with other systems, either 

currently fielded or planned to be fielded. Without an integrated concept for 

the squad level communication system, the Rifle Squad will receive laptops 

-7- 



and /or Personal Digital Assistants (PDAs) from one POR, radios, Global 
Positioning System (GPS) units, and alternative power sources all from their 
own respective POR. It is important to note that an integrated capability (as 
defined by the analysis) is required in order for a successful solution to be 
implemented. 

■ The Joint Tactical Radio System (JTRS) is the DoD mandated provider of 
future tactical radios and associated waveforms. The JTRS Joint Program 
Office (JPO) is currently developing a family of radios that are software 
programmable to support service elements, joint and other agencies at the 
tactical edge. The available JTRS products today are considered a viable 
material solution for Marine squad leaders. The examination of the 
alternatives to support a non-material or material approach is vetted via this 
Systems Engineering Design Process (SEDP) during our analysis. 

■ The Blue Force Track (BFT) policy, approved by the JROC, requires joint 
communication standards. This policy defines the capabilities to establish and 
maintain connectivity for Command and Control and Situational Awareness 
nodes. It also mandates adherence to a common, friendly force, plain 
language addressing scheme between friendly forces operating in theater. The 
BFT architecture relies on a mixture of US government and commercially- 
leased satellites and ground control stations. 

Other constraints listed below were used as entry criteria for the final system 
solution to be considered. MERS documentation, and input by Key Stakeholders led to 
these constraints being applied. Any potential alternative system had to meet the 
following conditions: 

■ Operate in Military Spectrum Bands (per FCC guidance) 

■ National Security Agency (NSA) certified or certifiable 

■ Joint Integrated Test Center (JITC) certified or certifiable 

■ JTRS Service Component Architecture (SCA) 2.2 compliant 

■ Requires no Satellite Communication (SATCOM) equipment at the squad 
level 
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■ Power system must support Mission Duration times no less than 8 hours 

■ Total system weight must be lighter than the currently fielded system 
configuration 

■ Operate independent of commercial telecommunications infrastructure 

■ Total Research, Development, Test and Evaluation (RDT&E) costs must be 
less than current PM MERS program funds 

■ Initial Operational Capability (IOC) in accordance with PM MERS 
acquisition documentation 

■ Full Operational Capability (FOC) in accordance with PM MERS acquisition 
documentation 

■ Backwards compatible with existing systems until FOC 

D SYSTEMS ENGINEERING METHODOLOGY AND APPROACH 

The Systems Engineering Methodology for the Squad Communication System 
was a tailored process adopted from original ideas and various existing systems 
engineering models. Models, concepts and methodologies include the Traditional 
Structured Analysis Model (Grady, 2009); concepts for functional, physical, and 
operational architecture development from D.M. Buede (Buede, 2000); and 
environmental classification definitions by Grady (2009). When these concepts were 
combined, a roadmap from a user need to a recommended alternative was developed to 
focus the team’s analysis. This roadmap provided the framework and direction of the 
effort, from need, concept development, alternative analysis and finally a recommended 
solution for the Rifle Squad Communication System. 
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Figure 5: Detailed Systems Engineering Process 
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The methodology begins with understanding the user requirements©. This 
includes the development of a preliminary problem statement that assesses what the user 
perceives as the need to perform operational tasks, the conditions in which they perform 
them, gaps in the current system, and inferences about the future state. These inputs help 
formulate needs and constraints of the system, the operational context in which it must 
perform, and the preliminary assessment of system boundaries. With this information, an 
intensive architecture decomposition effort can further define these contexts. The 
architecture development© involves the operational, functional, and physical 
decomposition to further develop the context of the system and create the basis of 
performance requirements while being bounded by the Operational Concept. The end 
result of this decomposition is a well defined functionality that the system must fulfill 
within the larger context of the Marine Corps and a work breakdown structure®. 

In parallel to the sub-system definition, a complete analysis of the intended 

environments© and specialty engineering aspects© of the system will give sufficient 
depth to the requirements development. The breadth of environments include internal 
environments the system itself creates, external environments that the system operates in, 
and interfacing systems beyond the scope of the system that is being defined. Specialty 
engineering aspects are captured to envelop the higher system level requirements that are 
not captured within the decomposed functions For example, system reliability, 
maintainability and survivability are defined at the highest system level and then flowed 
down to the sub-systems in future iterations. These specialty engineering aspects also 
bound the system tradespace to work within the established USMC maintenance, logistic, 
and supply system. Environment and specialty engineering analysis make up the non¬ 
functional portion of the objective hierarchy. 

When the functional and non-functional requirements converge, Measures of 
Effectiveness (MOEs) are developed for all requirements to make up the Objective 
Hierarchy©. These MOEs are the basis of a system level performance specification or 
capabilities development document (CDD). However, for the purposes of this analysis, 
an Objective Hierarchy will be sufficient to complete the methodology. The 
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requirements analysis© provides the complete linkage between the measures of 
effectiveness and allocation to a sub-system developed from the physical architecture. 
This linkage is the key to future refinements of the system beyond the early concept 
phases of the program. This helps provide a foundation for good systems engineering 
and a backbone for sound program management. 

From the high level description of the sub-systems, (defined from the architecture 
decomposition and the physical architecture)^, the system is then decomposed into the 
next layer of abstraction, where actual hardware elements are assigned to the physical 
architecture. Ideally all the system needs, defined in the objective hierarchy, are 
represented by the hardware elements. Alternative Generation® is developed using a 
morphological box or similar brainstorming exercise to ensure all ideas are considered. 
Alternatives are screened for feasibility and grouped together to make a complete system 
as described in the physical architecture. At this point in the methodology, the hardware 
chosen to make up the system can be analyzed for cost ® and risk® to contribute to the 
alternative analysis©. A completed alternative analysis will result in a recommended 
alternative. This methodology is an iterative process that is the foundation for future 
systems engineering work as the system undergoes further definition to the component 
and sub-component level. This methodology also provides the necessary roadmap and 
traceability when requirements evolve as the needs of the Marine Corps evolve. 


- 12 - 


II PROBLEM DEFINITION 


During the Problem Definition phase of the design process the team focused upon 
interdisciplinary methods for defining a vision of what constitutes a system, in terms of 
meeting the stakeholder needs. Problem definition is crucial as it establishes the basis for 
all subsequent analysis and evaluation of the project. 

A PROBLEM STATEMENT 

Joint Requirements Oversight Counsel Memorandum 071-08 directs for U.S. 
Forces to explore alternatives for enhanced communications and networking. It also 
identifies the need for an enhanced Blue Force tracking capability for Command and 
Control (C2), and Situational Awareness (SA) that supports seamless exchange of 
information between operating forces in joint operational areas. (Note: Blue Force 
tracking is a United States military term used to denote a Global Positioning System 
(GPS) enabled system that provides military commanders and forces with location 
information about friendly military forces). 

This memorandum addresses a need to promote sharing of secure/unsecured 
position location information and relevant SA information between combatant 
commanders, services, and agencies. Senior level leadership has determined that squad 
level and below communications are mission dependent and may have varying levels of 
classification; therefore, the telecommunications devices used by the squad must also be 
able to satisfy all missions. In addition, current programs fall short of supporting a 
MERS net centric capability today. The challenge now for the Marine Squad Leader is 
executing the mission effectively as a maneuvering element of the rifle platoon with the 
existing “status quo” communications solution. The primitive need of this project 
focuses on finding a system that could adequately address the command and control and 
situational awareness capability required by the Marine Corps. 
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B NEEDS ANALYSIS 


1. Stakeholder Analysis 

Requirements are generally considered the cornerstone of the systems engineering 
process. Originating requirements are those requirements initially established by the 
system stakeholders with the help of the systems engineering team. The systems 
engineering design process is a mixture of establishing requirements to define the design 
problem and portioning the physical resources of the system into components that 
perform functions that meet the requirements. Many important decisions are made by the 
systems engineering team that will ultimately affect the performance of the system and 
the satisfaction of the stakeholders. (Buede, 2000) 

A stakeholder analysis was conducted to gain a better understanding of the needed 
capability and determine customer desires from a holistic view, with the goal of 
addressing joint and service requirements. 

a. Stakeholders 

The stakeholders that have a vested interest have been identified from the 
following groups of clients, decision-makers, sponsors, users, and analysts. The key 
stakeholders for this undertaking were determined to include, but are not limited to the 
following organizations: 

(i) Policy & Decision Makers 

■ Joint Forces Command (JFCOM) oversees joint services transformation 
including Concept Development and Experimentation, Training, 
Interoperability and Integration according to Unified Command Plan (UCP) 
(2008). JFCOM helps develop, evaluate, and prioritize the solutions to the 
interoperability problems plaguing the joint war fighter. 

■ Headquarters Marine Corps (HQMC) Command, Control, Communications 
and Computers (C4) is responsible for the planning, directing, coordinating 
and overseeing, C4 and Information Technology (IT) capabilities that support 
the warfighting functions, and influences the combat development process by 
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establishing policy and standard for developing the enterprise architecture to 
achieve Joint and combined interoperability. 

(http://www.hqme.usme.mil/PP&0) 

■ HQMC Plans Policies & Operations (PP&O) is responsible for the 
coordinating the development and execution of service plans and policies 
related to the structure, deployment and employment of Marine Corps forces. 
(http://www.hqme.usme.mil/PP&0) 

(ii) User Representatives 

■ Marine Corps Squad Leader is responsible for carrying out missions 
communicated to him by his Platoon Commander through the effective 
management of the squad and squad resources. 

■ Marine Corps Combat Development Command (MCCDC) is responsible for 
the development of fully integrated Marine Corps war fighting capabilities; 
including doctrine, organization, training and education, materiel, leadership, 
personnel, and facilities, to enable the Marine Corps to field combat-ready 
forces, (https://www.mccdc.usmc.mil). 

(iii) Acquisition Agents and System Developers 

■ Marine Corps Systems Command (MCSC) Deputy Commander, Systems 
Engineering, Interoperability, Architectures and Technology (DC-SIAT) 
serves as the principal agent for acquisition and oversees the development of 
the complex systems that equip today’s Marine force. 
(http://www.marcosyscom.usmc.mil/sites/siat). 

(iv) Evaluators & Analysts 

■ Marine Corps Operational Test & Evaluation Activity (MCOTEA) provides 
operational testing and evaluation on behalf of the Marine Corps and conducts 
additional testing and evaluation as required to support the Marine Corps 
mission to man, train, equip, and sustain a force in readiness. 
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■ Marine Corps War-fighting Laboratory (MCWL) improves current and future 
naval expeditionary warfare capabilities across the spectrum of conflict for 
current and future operating forces. 

b. Stakeholder Approach 

The approach for capturing the stakeholder needs included questionnaires, 
interviews, and research that determine the values germane to transforming the primitive 
need statement. A questionnaire (in APPENDIX D) was designed to facilitate describing 
the problem from points of view from all stakeholder groups. The stakeholders provided 
responses. Research of source documents was also incorporated within an affinity 
diagram, which was used to arrange and group ideas. 

c. Policy Makers 

Research of policy documents produced a joint operational capability with respect 
to the problem space of marine expeditionary rifle squad communications. The JROC 
approved position location information (PLI) classification and security policy for blue 
force tracking system determines a need for C2, and situational awareness at the edge of 
the battle field. The policy guidance for the marine squad communications system is 
traceable back to the following joint capability requirements: 

■ Forces using two-way C2/SA systems must protect aggregated BFT PLI data 
at the confidential or higher level of classification. All devices operated at 
this level that transmit and receive aggregated PLI data must be designed to 
protect this data to a level merited by classified information. 

■ PLI classification is mission dependent. PLI may be either unclassified or 
classified depending on mission and combat conditions. 

■ Friendly force units operating in a battlespace or other combatant commanders 
declared operating area must employ capabilities that protect exploitable 
(nonperishable, survivable) PLI data as classified. 

■ Both transmission security and crypto logical security are necessary to protect 
a PLI system or family of systems from exploitation. 
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■ PLI systems should be designed to optimize both types of security. Combatant 
Commanders may establish particular mission-dependent guidance applicable 
to generation, transmission, and handling of PLI data for forces operating in 
the air, space, maritime, and ground domains. 

■ Forces may protect one-way, non-aggregated PLI data to less than secret, but 
as a minimum must protect to the level merited for controlled unclassified 
information (CUI), and certified by NS A. 

d. Acquisition Agent Feedback 

Examination of Marine operating concept source documentation illuminated an 
operational capability that meets the needs of the USMC for MERS communications. 
Specifically, squads require advanced, integrated, and multi-purpose systems for 
communication, location, and identification. These assets must be capable of calling for 
fires and coordinating with other physically separated units moving throughout an 
expanded battlespace. Focused, realistic and demanding training is probably the single 
most critical element for development of rifle squad capabilities. The squad leader and 
fire team leaders require more robust and expanded training in several critical areas to 
ensure they develop the independence, self-reliance, and confidence to handle more 
demanding situations. Maneuver units and fire support assets must be able to identify 
small friendly units distributed across the battlespace. (MERS Draft Tactical Operating 
Concept, 2009). The following were recommendations from the acquisition agents: 

■ Develop an Initial Capability Document (ICD) for MERS 

■ Create a formal Program Objective Memorandum (POM) initiative for MERS 

■ Continue dialog with the operational forces to identify evolving needs 

■ Continue socializing the concept to USMC leadership 

■ Develop Capability Development Documents (CDDs) to identify the highest 
priority required capabilities as determined by the war fighter input 

e. Clients and Users Feedback 
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Questionnaire responses from the user community gave insight on the 
communications solution of today, and provided feedback on additional capability 
desired by the end-user. The current communication capability fielded has two radios for 
the squad leader to conduct communications vertically, and horizontally. The first radio is 
a AN/PRC-152 with NSA approved encryption for voice only communications between 
the squad leaders and platoon commander. The second is an Interim Intra-Squad Radio 
(IISR (AN/PRC-153)) with commercial encryption for voice only communications 
between squad leaders and squad members. This communication approach has its 
drawbacks from an integration stand point because of the additional devices required to 
conduct communication during missions. 

The following desired capabilities were identified by the users: 

■ A tracking capability for infantry units is a necessity for situational awareness 
back to command. 

■ The Marine squad missions now call for a non-terrestrial multiband waveform 
based capability for interoperability between various communications devices 

■ A common encryption scheme to reduce logistical requirements 

■ A data information sharing capability is needed for non-verbal information 
exchange 

■ Interoperability between coalition, service elements, and other agencies for 
joint missions 

■ Ruggedized equipment with enhanced durability for different operational 
environments. 

■ Training, ease of use, ergonomics, for communicating rapidly 

■ Current implementation requires multiple devices to conduct operations. 

f. Evaluators and Analysts Feedback 

The project team conducted a Human Factors Engineering Analysis on the 
currently deployed primary squad level radio (AN/PRC-152) to determine the 
usability from a Squad Leader perspective. The goals of the analysis were to identify 
causes of increased human error, task time, and workload. 
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Today the USMC Squad leader is mentally over-tasked and physically over¬ 
burdened. The execution of the missions requires communicating the orders for the 
tactical employment, fire discipline, and fire control of the squad during close 
engagement with the enemy. The analysis recognized human factors challenges to 
include: 

■ There is no formal training provided to the user for the IISR (AN/PRC-153) 
radios. The platoon level and below (Users) are often given on-site informal 
training as needed or during exercises and are given a comprehensive manual 
with the radio, for reference. 

■ The Liquid Crystal Display (LCD) on each of the fielded radios lacks an 
antiglare protection which makes the black text on a green or gray background 
hard to read in bright sunlight. In addition, both radios use different font sizes 
and the smallest font characters are extremely difficult to view unless the 
radio is held closer to one’s face. 

■ The weight and size of the AN/PRC 152 radio is approximately 2.6 lbs. 
without the whip antenna, and approximately 3.3 lbs. with the antenna. This 
device is top heavy when held in the middle with one hand, which creates a 
torque effect on the wrist. A holster is used primarily once the radio is 
configured. 

■ The channel selection and transmission switch are difficult to view in low 
level lighting. The switch is not illuminated for night missions, and the 
encryption type that the radio uses is not intuitive. 

2. Affinity Diagram 

The results of the team’s research and interviews with key stakeholders enabled 
the needs analysis effort and resulted in focused information gathering. An Affinity 
Diagram is used to organize and group information. The process began with the 
generation of feedback from the stakeholder interviews. The feedback was displayed for 
the sole purpose of searching through the data with the premise that similar ideas were 
grouped together and unrelated feedback established new groups. The ideas that are 
similar were added to the same groups, and unrelated feedback established new groups. 
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The “ Improvement ofUSMC squad to share and communicate” affinity diagram is seen 
in Figure 6 below. 
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Figure 6 Affinity Diagram 

3. Effective Needs Statement 

After fully examining the results of all of the needs analysis tools, the team 
developed the following effective needs statement: 

The Marine Corps requires a device or devices that will equip the squad leader 
and members with the ability to communicate key information exchanges to 
perform their mission. The communications equipment must meet doctrinal 
mandates and provide reliable, covert, secure, timely and accurate information 
when and where needed. 

Key verbal and non-verbal information exchanges are: 

■ Geographic location / Position Location Information (PLI) 

■ Mission objectives / Commanders Intent and Orders 

■ Personnel status, equipment status, weapons and ammunition 

4. Input-Output Model 
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The system must meet the minimum capability to transmit, receive, and process 
voice communications with input via a microphone and output via a speaker. Based on 
the effective need statement above, the system must also provide the additional capability 
to transmit, receive, process, and display digital data, in textual and graphical 
representations. For example the system must display and transmit the member’s PLI 
with latitude and longitude readings. The system must also provide additional 
networking capabilities, or connectivity in order to support a suite of other netted sub¬ 
systems, Command & Control (C2) and Situational Awareness (SA) systems or devices, 
(such as a personal processing device, a BFT system, Marine health monitoring devices 
and weapon monitoring devices, etc.). These additional devices must be able to interface 
with the system but are not considered part of the transmission system. The devices must 
operate in combat conditions, requiring the ability to control light emitted and the ability 
to increase or decrease audio output. 

In Error! Reference source not found, below the team developed a simple view 
of the inputs and outputs of the communication system at the squad level. This view 
provides a partial list of controllable and uncontrollable inputs and their respective 
outputs after the system has processed them. This list is not all inclusive but is a focused 
set of parameters based on existing communications systems in the current operational 
environments today. Currently the fielded system only processes voice communications 
as the input into an audible output. 

Ultimately the squad communications system will provide the squad leader the 
ability to receive, transmit, generate and process both voice and digital data sets of 
information simultaneously, (i.e. formatted message sets, free text or chat, GPS 
coordinates, etc.). 
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Figure 7: Input - Output Model 

For example, the system should receive a digital image with annotated text while 
the squad leader is using his or her voice to update the squad’s current position to the 
platoon commander. The desired output of this example is an error free image received 
as well as a clear, un-garbled audio message acknowledged by the platoon commander. 
Other parameters listed in the diagram are described below: 
a. Controllable Inputs: 

The operator must have the ability to select one or multiple channels to 
accomplish voice and data transmissions across directed radio and networking channels. 
This operation can be pre-planned, automated, or manually applied based on operator 
requirements. 

The encryption material will be in the forms as designated by NS A and in keeping 
with common operating Tactics, Techniques and Procedures (TTPs). The physical 
inputting of the encryption algorithms may be automated or manually inserted. 

Data sets with formatted descriptive elements, such as Operational Orders, 
Fragmentary Orders, Warning Orders and Free Text Messages will be created or 
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published. These data sets will be created or published by other Command and Control / 
Situational Awareness (C2/SA) devices in digital formats applicable to wireless 
transmissions. For the purposes of this project it will be assumed that these C2/SA 
devices will interface with a network capable radio/transmission device. 

Additional information systems relying on an available network capable system 
could include automated Weapons Systems Status, Individual Health Monitoring, and 
other systems reporting details relevant to the operating environment. Inputs will be 
enabled via networking interfaces like Universal Serial Bus USB, Ethernet, and Serial 
ports. 

b. Uncontrollable Inputs: 

With all digital transmission systems, the introduction of networking anomalies, 
audio feedback, environmental effects, and electromagnetic effects must be anticipated 
and the transmission system must be able to overcome and adapt to the challenging 
networking environment as experienced on the battlefield. 

c. Controllable Outputs: 

Outputs will be enabled via networking interfaces. As a result of the ability to 
transmit and receive digitized voice and data, the system output will be audio or data 
elements translatable by the system or netted sub-systems. These received and processed 
data and voice elements will result in individual and unit C2/SA capabilities. The voice 
digital outputs will be formatted for direct audio output to speaker system. The data 
digital outputs will be formatted for direct translation to connected individual C2/SA 
devices. At a minimum the system must be able to transmit process and receive ah 
formatted audio transmissions and formatted position location information (PLI). 

d. Uncontrollable Outputs: 

Cross-talking circuits, network interruptions, garbled or unreadable data and other 
data elements can be expected for devices operating in this environment. The system 
must be able to overcome these obstacles but the processing and data formatting are again 
resident in the network sub-systems and not a required capability of the communication 
system. 
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The 10 model in Figure 7 provided the SE Team another tool that described the 
basic information flow of data and the basic functions expected of the communications 
system at the squad level. In other words the team used the 10 model to determine, 
‘What does the system need to do?’ rather than try to resolve ‘How does the system do 
it?’ The description of the system then allowed the team to move forward into the 
functional analysis. 
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Ill DESIGN 


A FUNCTIONAL ANALYSIS 

The end state of the functional analysis was to establish an operational, functional, 
and physical architecture of the squad communication system in order to provide 
traceability to the user requirements and operational context of the system. This is 
accomplished through several decomposition iterations of the three architectures 
throughout the systems engineering methodology. All three architectures represent the 
logical model that D.M. Buede describes as the transformation of inputs into outputs. 
(Buede, 2000). Through several iterations, the logical model is better defined at lower 
levels of abstraction. These lower levels of abstraction describe the intricate nature of the 
system. With well defined logical models, the system description can evolve when the 
environment, requirement, or operational context changes to maintain relevance. The 
logical models were developed with a tailored Integration Definition for Function 
Modeling (IDEF) technique to graphically convey these relationships of inputs and 
outputs. (National Institute of Standards and Technology, 1993). 

The three architectural views of the squad communication system are essential to 
form the context and objectives of the system. The functional and physical architectures 
closely followed the definition established by D.M. Buede as a decomposition of the 
function to which the system needs to perform in order to meet the needs of the 
operational architecture. (Buede, 2000). The operational architecture used in the analysis, 
which is consistent with D.M. Buede’s three architectural view framework, was a hybrid 
development based more closely to the Department of Defense Architectural Framework 
(DODAF) Operational View. This operational architecture approach improved 
traceability to the system of systems architecture from the MERS ICD and architectures. 
The MERS system of systems architecture (Figure 8) becomes the platform to align 
functions performed by the Marines within the operational context. A hybrid approach 
ensured consistency and traceability to the larger system of systems view. 
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Figure 8: MERS System of Systems Architecture 

1. Operational Architecture 

The Operational Architecture provides the purpose of the system within the 
operational context. The Operational Architecture is the graphical decomposition 
consistent with the DoDAF Operational View Three (OV-3) which describes the 
relationships, information flow, and information content. (Wisnosky, 2006). These are 
the critical information exchanges that the communication system must process to carry 
out the missions defined in the MERS Architecture. (MERS Architecture Final Practicum 
Project Report, June 2008). Missions are defined in this study as the tasks, together with a 
purpose, that clearly indicate the unit’s actions to be taken. (“Joint Publication,” 2009). 
The Operational Architecture defines the required minimum communication messages 
that the Marine Squad Leader must process to provide command and control of the squad 
fire teams and the necessary communications to higher headquarters. This information 
exchange contributes to the Common Tactical Picture (CTP) during all missions. 

The required communication messages and functions used for the Operational 


Architecture were allocated and decompose from the higher level communication 
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function in the MERS Architecture. The Operational Activity Model (OV-5) (See 
APPENDIX C) provided the activities or functions, while the Operational Information 
Exchange Matrix (OV-3) (See APPENDIX C) provided the information exchange or 
communication messages required to perform these functions. (MERS Architecture Final 
Practicum Project Report, June 2008).When the OV-3 and OV-5 communications 
functions were developed in modified IDEF models the inter and intra-nodal 
relationships helped shape the necessary functions to process the communication 
messages effectively. For example, a majority of messages in the operational architecture 
require a geographic position of the squad and fire team. Therefore at the system view, 
the communication system needs to have a global position function to carry out the 
operational function or needs a defined interface to another MERS system that will 
perform that function. Functions such as target location, ammunition status, and 
equipment status were allocated to other MERS systems, and are not within the boundary 
of the communication system. 

The operational view was also used to define the different levels of classification 
required when sending messages. The need for cryptographic material was defined in the 
problem definition, but the operational architecture provides a mental model of the 
relationships for each level of classification required. Figure 9 shows the inter-nodal 
diagram of the Marine squad with the different levels of cryptographic material needed to 
provide secure communications. (MERS Architecture Final Practicum Project Report, 
June 2008) 
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Figure 9: Operational View Inter-nodal Diagram 

The Squad Communication System Operational View AO (Figure 10) models the 
inputs and outputs of the various messages required for the squad to be an effective part 
of the CTP and supply sufficient command and control of the squad. The messages 
identified in Figure 10 are the minimum set of structured messages. Communication 
takes many forms and cannot be accurately accounted for in the system, but can be 
grouped sufficiently under the communication messages modeled. 
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SQD Terminal Weapons Guidance - Mech-Armor Support 

SQD Terminal Weapons Guidance - NSFS Group 


SQD Terminal Weapons Guidance - FSCC 


SQDL Fire Notificaiton 


SQDL Mission Provision Requirement 
SQDL SMEAC Brief 


SQDL SMEAC detail request 


SQDL CMD Execute Mission 


SQDL Tactical Commands 


SQDL Terminal Weapons 
Guidance - Secure Perimeter 


SQDL Fire Support Request 

-Assault Enemy Position 


SQDL Command to Fire 


SQDL Friendly Locations 


SQDL Enemy Locations 


SQDL Fire Control Plan 


SQDL Causality Status Report 


Process Fire 
Team 

Communication 
/ Information 


A2 


Crypto 

Classification 

FT - Fire Team 

Type 1 

AJS - Adjacent Joint Squad 

Type 2 

ACS - Adjacent Coalition Squad 

AMCS - Adjacent MC Squad 

None 

PLT - Platoon Leader 


FT Geographic position _ 

FT Enemy Location Report 
FT Situation Update ~_ 

FT Ammunition Resupply Request _ 

FT MEDEVAC Request FT CASEVAC _ 

FT Equipment Status _ 

FT Obstacle Report _ 

FT Provision Status Report - Other 

FT Tactical Situation - Coordinate Manueuver _ 

FT Tactical Situation - Force Protection Measurements 

FT Fire Fight Status - Coordinate Fire Support 
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FT Provision Status Report - Ammo 
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Node: AO 

Title: Squad Communications 

1 of 1 


Figure 10: IDEF-0, Operational View, AO 
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The primary operational function for the squad communication system is to 
Process Squad Communication/Information. This can be decomposed into two functions: 
Process Squad Leader Communication/Information and Process Fire Team 
Communication/Information. It is assumed that both the squad leader and fire team will 
have common systems and equal capability to process messages. The inputs to the squad 
leader are messages across the range of nodes depicted in Figure 9. This squad leader 
function transforms messages into actions to perform the required missions of the Marine 
Squad. The required missions were defined as functions at the next layer of abstraction 
as seen in Figure 11 Operational View Al. By doing a complete decomposition, all 
required messages to perform the mission function were identified. 

These communication messages are not defined as voice or data, but have the 
same information attributes regardless of the message form transmitted. The forms will 
remain generic throughout the functional decomposition in order to allow an open 
approach to alternative generation. Depending on the alternative, either form may be 
used. The Operational View Al (Figure 11) decomposes block Al to four functions: 
Plan Mission, Control Mission, Report Mission Status to Higher Headquarters, and 
Organize Consolidation / Reconstitution. 

The complete Operational Architecture is located in APPENDIX E. Since the 
Fire Team is the major action unit for the mission, the A2 block was decomposed to the 
next level of functional abstraction. At the fire team level, the focus was limited to 
Marine squad missions of Movement to Objective (by foot), Linkup, Reinforce, Passage 
of Lines, Infiltration, and Obstacle Crossing/Reduction as defined by the MERS 
Architecture OV-5. Other MERS missions of Movement to Objective via Ground, 
Amphibious, and Air Vehicles were not evaluated because it is assumed the host vehicle 
will support the required communication functions until the squad is dismounted. 
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View: Operational 

Node: A1 

Title: Squad Leader Communications 

1 of 1 


Figure 11: IDEF-O, Operational View, A1 







































































































































2. Functional Architecture 

The operational view defined the communication messages exchanged for each 
mission. The functional architecture defines how the system will process those 
communications messages. The functional architecture will be allocated to the physical 
architecture and will define the squad communication sub-systems. 

The Functional Architecture AO (Figure 12 ) was used to answer: 

■ How will the system processing incoming messages, decipher data, and 
convey to the user? 

■ How the system will generate the required data and send messages to the 
various nodes described in the Operational View Inter-nodal diagram? 

■ What are the required internal and external interfaces? 
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Figure 12: IDEF-0, Functional View, AO 
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The system was then decomposed into the following functions: 

■ Receive Communication Information (Al) includes receiving the signal / 
waveform, and demodulation of the signal into an appropriate form for 
processing. 

■ Process Communication Information (A2) includes the determination of the 
type of communication (I, II, or clear ), decryption of the communication if 
needed, processing of the incoming or generated communication, storage of 
data for later use, storage of the encryption of key material (I or II), and 
finally the re-encryption of the communication for later transmission. 

■ Generate Communication Information (A3) generates the required 
communication information in either data or voice communication and 
modulated the input for communication processing. 

■ Convey Information to User (A4) converts the signals processed in the 
systems and either displays the information or broadcasts the voice 
information to the user. 

■ Transmit Communication Information (A5) is the inverse of the receive 
communication in which the signal is modulated, amplified, and transmitted. 

■ Provide Power (A6) provides the inherent capability required to facilitate the 
other functions. This assumes that the system must be self-sufficient and not 
allocated to another system within the MERS concept. 

3. Physical Architecture 

The Physical Architecture allocates the functions from the Functional 
Architecture to sub-systems which are further defined as actual hardware or software 
components. This allocation also defines what the sub-system is required to perform to 
make the system operationally effective. Most functions have a one-for-one traceability 
to the physical architecture with the exception of the receiver / transmitter sub-system 
(Figure 13). 
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Figure 13: Traceability from Function to Sub-system 


The Physical Architecture (Figure 14) was derived from the functional trace 
performed above and can be used as simple program Work Breakdown Structure (WBS). 
The elements are generic descriptions of the key sub-systems which will eventually be 
decomposed to hardware, software, and human components later during system design. 



View: Physical Node: Title: Physical View: Squad Communication System 


1 of 1 


Figure 14: Physical Architecture 

The Functional Architecture is related to both the Objective Hierarchy and Physical 
Architecture and traceable to both products (See section IIIA2 above) 
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B VALUE SYSTEM DESIGN 


In order to determine the evaluation measures important to the Marine Squad 
Leader, the team met with members of the Marine Expeditionary Rifle Squad (MERS) 
program office staff. The group created a list of attributes for the new system as depicted 
in Table 1: System Attributes 


Table 1: System Attributes 


Weight 

Volume 

Capability 

Ease of use 

Battery duration/life 

Durability 

Voice 

T ext/data/ images 

Anti-spoof 

Redundancy 

Security 

Bandwidth 

Reliability 

Range (miles) 

Easy to learn 

Easy to remember 

Size/transportable 

Status Indicators 

Commonality 

Modularity 

Multiple 

environments 

Interoperability 

Adaptable power 
source 



1. Objective Hierarchy 

The development of effective value criteria, as expressed in an Objectives 
Hierarchy, is critical to successful project development. The Objective Hierarchy is 
intended to ensure that the correct objectives and measures of effectiveness have been 
identified so that the correct system is designed and successfully validated against the 
needs, expectations, and constraints of the ultimate end user, the USMC. 

2. Value System Modeling 

Using existing documents and discussions with key stakeholders, USMC subject 
matter experts, and other research data, previously identified in this report, the Team has 
defined the Effective Need Statement and functional decomposition of the top level 
functions to develop the Objective System Hierarchy shown in Figure 16 through 19. 

The Objective Hierarchy provides a top-down approach starting with the 
Functional and Non-Functional Attributes derived from the Effective Needs 
Statement, (described in Section IIB3), and subsequently flowing down into two 
major categories namely Functional and Objective Hierarchy (Figure 16 and Figure 
17) and Non-Functional Attributes and Objectives (Figure 18 and 
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Figure 19). Specific measures of effectiveness are assigned to each objective for 
Analysis of Alternatives (AoA) and verification purposes. 

Selection of the measures of effectiveness is based on the requirements derived from 
the available documentation as they apply to the system along with other requirements 
discovered by the Team as part of Needs Analysis. For example, stakeholder analysis has 
identified the ability to communicate to both higher and lower echelons via one radio as 
one of the most important objectives driving the need for a communications system. 
Therefore weight and volume are typical measures of effectiveness that are used in the 
decision making process. Attribute N5, chosen to ensure usability and human factors uses 
weight, volume, maximum total workload and operational use as the measures of 
effectiveness used to evaluate this attribute. 

The system must be operational and maintainable in all types of climate and terrain 
where Marines deploy or may deploy. Therefore maximum and minimum temperature, 
quantity of rain, snow, ice, and wind velocity are important measures of effectiveness. 
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Attribute N6 references military standards that state the environmental requirements and 
these requirements must be met by each alternative in order to be considered in this 
evaluation in order to ensure operation in all environments. 

Duration of power and percentage of incoming and outgoing messages processed are 
some of the other measures of effectiveness used in the decision making process. 

Each measure of effectiveness is depicted in a box at the end of its corresponding 
bottom level function/objective. The measures of effectiveness denoted with an asterisk 
are used to evaluate the different alternatives discussed in section IIIB3 below. 

The team chose the measures of effectiveness to use in the decision making process 
by determining what data would provide the greatest distinction between the alternatives 
and could be gathered from the modeling and simulation process and the research 
sources. 



Communications System 


Functional Attributes 


Non- Functional Attributes 


2 

Figure 15: Functional and Non-Functional Attributes 

Selection of the measures of effectiveness is based on the requirements derived 
from the available documentation as they apply to the system along with other 
requirements discovered by the Team as part of Needs Analysis. 

Functions Al, A2, and A5 [Figure 16] are related to the radio(s) associated with 
the squad leader communications system. The stakeholder analysis identified the ability 


Al: Receive Communications 


A2: Process Communications 


A3: Generate Communications 


A4: Convey Communications 


A5: Transmit Communications 


A6: Provide Power 


Nl: Survivability 


N2: Reliability 


N3: Availability 


N4: Maintainability 


N5: Usability / Human Factors 


N6: Operational Conditions 
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to communicate to both higher and lower echelons via one radio as one of the most 
important objectives driving the need for a communications system. Therefore goals and 
MOEs associated with the radio system were focused on ensuring the radio(s) worked as 
multiband radios with proper encryption and little to no errors associated with the 
objective single radio development. 

Function A6 [Figure 16] addressed another identified area of great importance 
based on analysis and stakeholders desire for lighter and more efficient power generation 
capability. This was evaluated by collecting raw data and specifications on available 
batteries. 

Functions A3 and A4 [Figure 17] are related to the information processing 
capability associated with the integrated communications system. The goals and MOEs 
associated with these objectives are to ensure the user interface and input/output devices 
reduce human and system error. Through interviews and analysis of after action 
comments it was quite apparent that the squad leader’s primary focus cannot be taken 
away from his tactical tasks to deal with inaccurate or erroneous information being 
conveyed to him. He must be able to trust the information and data being offered to him 
as factual and reliable or the system becomes a hindrance vice an asset. 

Attribute N5 [Figure 18] deals with human factors; form factor, weight ease of 
use, user interface simple configuration and operation, etc. If the system’s benefits do 
not satisfy the operator, then the system will be characterized as operationally ineffective 
and will not be used during operations. Part of this attribute was evaluated with raw data, 
a cognitive model and evaluated by the team via a Likert scale. 

Attributes N2, N3, and N4 [ 
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Figure 19] are related to the system’s reliability, availability and maintainability. 
Through the needs analysis, interviews and stakeholder analysis it was determined that 
the squad leaders will only take equipment to the field that they have full reliance on and 
can be almost certain that it will not break or become ineffective during a mission. The 
packed out load for a Marine is near 95 pounds already and near unbearable by most. 
Any additional weight will only be acceptable if the system brings added utility with 
minimal impact to the operators. 

Attributes N1 and N6 [ 
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Figure 19] are directly related to a physical and electronically hostile 
environments. The system must survive enemy electronic counter-measures as well as 
the rigors associated with operating in a combat zone that promises anything but a “walk 
in the park.” Attribute N6 references MIL-STD 810, a military standard that defines the 
environmental requirements that must be met by each alternative in order to be 
considered in this evaluation, thus these measures were colored Blue to represent that 
without meeting these requirements, then the alternative was discarded. 

Attributes Al, A5 and N6 are considered to be the entry criteria attributes. All 
alternatives had to meet these in order to be considered and thus could have been used in 
the feasibility screening process. However, the team determined that these attributes are 
unique to each system being considered and thus could be considered and used as 
differentiating MOEs. 
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Function 


Sub-Function 


Goal 


Measure of Effectiveness 


A1 


Receive 


Communication 

Information 


A2 


Process 

Communication 

Information 


Crypto Processing 


Processes Communication 


Store Data 


Receive Multi-band, Multi-channel, 
Tuned Military Spectrum RF Signals 


HF, VHF, UHF Ranges (Hz) 

Number of simultaneous channels 




Maintain Waveforms & Encryption 


Data Memory Storage (Mbytes) 

Increase crypto processing accurately 

Minimum Error Rate (%) 

Process Communication messages faster 

Message throughput (%) * 

Store enough data to complete mission 

Data Memory Storage (Mbytes) 


A5 


Transmit 


Communication 

Information 


A6 


Provide 

Power 


Generate Power 


Store Power 


Transfer Power 


Functional Attributes 


Transmit Multi-band, Multi-channel, 


HF, VHF, UHF Ranges (Hz) 

Tuned Military Spectrum RF Signals 


Number of simultaneous channels 



Increase power generation (endurance) 


Peak power generated (Watts) 

Increase power storage 


Duration of power (hours)* 

Increase power transfer efficiency 


Supply efficiency (%) 


Modeled 


Raw Data 



Evaluated 


Required 


Attribute Objectives 


Figure 16: Functional Attributes and Objectives 
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Function 


Measure of Effectiveness 


Sub-Function 


Goal 




CO 

J 

( \ 

Convert Data Accurately 

V J 



Generate 

Information 

From User 

V _ J 

f \ 

Input Audio Information 
^ J 

r \ 

Input Visual Information 
v_ ) 


Decrease Digital Data or Analog Voice 
Error and latency 


Error Rate (%)* 

Latency (ms) 



Increase accuracy & timeliness 


Error Rate (%)* 

Audio data 


Latency (ms) 



Increase accuracy & timeliness 


Error Rate (%) 

Visual data 


Latency (ms) 



Decrease Digital Data or Analog Voice 
Error and latency 


Error Rate (%)* 

Latency (ms) 



Increase accuracy & timeliness 


Error Rate (%)* 

Audio data 


Latency (ms) 



Increase accuracy & timeliness 


Error Rate (%) 

Visual data 


Latency (ms) 


Modeled 


Raw Data 



Evaluated 


Required 


-► - 

Functional Attributes Attribute Objectives 

Figure 17: Functional Attributes and Objectives (cont) 
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Attribute 


N5 


Ensure 

Usability 

& 

Human 

Factors 


Description 


Minimize Weight 


Physical Size for handheld use 


Comprehensive Visual Data 


Comprehensive Audio Data 


Ability & Complexity to 
Consume Analog & Digital Data 


Ability & Complexity to 
Create Analog & Digital Data 


Goal 


Measure of Effectiveness 


Reduce weight from the status quo 


Weight Reduction (lbs/ozs)* 


Reduce size from the status quo 

Volume Reduction (in 3 ) 

Maximize Display & Character Size 
in all conditions 

Screen Dimensions (in) 

Readability (Likert Scale 1-7) 

Maximize Quality 

Clarity in all conditions 

Tone Frequency (Hz)) 

Gain (dB) 


Minimize Workload of operator 


Workload assessment rating (1-7)’* 


Easy to Configure, Program, & Enter Data 
Maximized Accuracy w/ Minimum effort 


Avg time to enter data (s) 


Avg time to enter crypto (s) 


Operational Use (Likert Scale 1-7) 5 * 


Modeled 


Raw Data 



Evaluated 


Required 


-► - 

Non - Functional Attributes Attribute Objectives 

Figure 18: Non-Functional Attributes and Objectives 
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Attribute 

Description 

Goal 

Measure of Effectiveness 




N1 

N 

Ensure 

EMP/EMI Resistant 

Maintain Operation in an EMI environment 

Increased SNR (dB) Gain 

Survivability 

V J 

Jamming Resistant 

Reduce effects of jamming 

Increased SNR (dB) Gain 



N2 

V 

A 

Ensure 

Reliability 

r \ 

Overall Reliability of 

Communications System 

Increase the mean time between failure 

Mean Time Between Failure (%)* 

N3 

A 

Ensure 

Availability 

( \ 
Overall Availability of 

Communications System 

Increase Operational Usage / Total Time 

In all conditions 

Operational Availability (%) 

In all conditions 

N4| Ensure 
Maintainability 

Overall Maintainability of 
Communications System 

Reduce MTTR 

MTTR (Hrs) 




Modeled 


Raw Data 



Evaluated 


Required 


-► 

Non - Functional Attributes 


-► 

Attribute Objectives 
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Figure 19: Non-Functional Attributes and Objectives (cont) 
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3. Evaluation Measures and Weighting 

After finalizing the Functional Hierarchy for the system, the team focused on 
defining the key evaluation measures and weights to be used for the Decision Matrix. 
The weights are based on the stakeholders’ inputs that were discussed earlier in this 
report. 


The values of the weights were based on the subjective assessment by the team of 
the stakeholder preferences. The team evaluated over forty measures of effectiveness 
that could be used as the foundation for the weighting factors. After a thorough review of 
the Needs Analysis and the stakeholder inputs it was apparent that the factors that had the 
greatest effect were associated with employability. Weight was selected as the best factor 
to encompass the key physical attributes of the system (size, weight, and transportability). 
Duration of Power was determined as the best factor to encompass power generation due 
to the fact that less duration requires additional spare power to be carried. The other 
factors associated with the squad leader’s interface to and reliance on an integrated 
system that would make the system worth adding to the combat load due to the increased 
capability offered to the squad leader. The agreed upon weighting for the seven 
evaluation measures are identified in Table 2 below. 


Table 2: Weighting Factors 


Evaluation Measures 
Weight 

Duration of Power 
Operational use 
MTBF 

Max Total Workload 
Incoming msg % processed 
Outgoing msg % processed 
Check Sum = 


Metric 

pounds 

hours 

1 though 7 scale 

% 

workload units 

% 

% 


Weighting factor 
20 
15 
15 
15 
15 
10 
10 
100 


The team used these weighting factors to evaluate the alternatives and determine 
the best Course of Action (COA) which is described later in the document. Physical 
characteristics of the radio (weight), operational characteristics of the radio (Power, 
Operational use, and MTBF), and cognitive characteristics of the user (max total 
workload, incoming message percent processed and the outgoing messages percent 
processed) were derived and selected as the key weighting factors in this study. While 


- 47 - 





there were other measures, the seven selected measures were based on stakeholder input 
and team analysis. 
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IV MODELING AND ANALYSIS 


A ALTERNATIVES GENERATION 

Prior to selecting products or solutions, a list of alternatives must be generated. 
Within the DoD, there are directives, and instructions that direct the SE process to utilize 
other means of analysis and evaluation, prior to selecting a solution. The following 
paragraphs describe these additional evaluations. 

1. Doctrine Organization Training Materiel Leadership Personnel and 

Facilities (DOTMLPF) 

Throughout the SEDP, it was quite apparent that a material solution would be 
required to achieve the desired squad leader communications and networking capabilities 
as outlined and described earlier in this report. The team spent a great deal of time in 
determining the material solutions and describing in detail how each alternative offers 
enhanced and evolving capability to the squad leader. All material solutions being 
evaluated for incorporation into military equipment must also be assessed on six non¬ 
material areas that are defined by the Defense Acquisition University as DOTLPF. 

2. Non-material Alternatives (DOTLPF) 

a. Doctrine 

The doctrine of the Marine Corps continues to evolve and adapt. Doctrine 
does not currently discuss or consider distributed squad offensive operations. Nor 
does it consider the affects of connecting and networking forces for situational 
awareness and command and control below the battalion formations. As the 
squad leader communications and decision making tools evolve, so must the 
doctrine evolve to adequately address the potential battlefield enhancements that a 
networked force can bring to bear in “networked operations.” 

b. Organization 

The current organizational construct addresses the squad as the smallest 
combat organization. The squad is currently organized as “trigger pullers” with a 
“point me in the right direction and let me go do the mission” perspective. With 
added C2 and SA capabilities it will be necessary to add or accommodate for 
advanced skill sets in line with the enhanced information technologies (IT). The 
squad will continue to be organized and tasked as the “trigger pullers” of the 
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Marine Corps but an organizational assessment must be conducted within the 
current structure of the infantry battalions to determine if the current company- 
platoon-squad-fire team organizations continue to be necessary. 

c. Training 

As the IT capability enhancements and the increased skill sets are 
addressed it is imperative to assess current squad level training. To the extent 
possible, no IT enhancements should dramatically increase training requirements. 

d. Leadership: 

Current Marine Corps leadership may not be ready or prepared for squad 
level distributed operations. These operations will have to be considered and 
properly reinforced as capabilities are added and squad connectivity changes 
tactics and the “information domain” within the battlefield. 

e. Personnel 

Additional personnel may have to be added to the current squad table of 
organization. Further assessment must be considered as the IT enhancements 
become realized and are employed effectively at this level of distributed 
operations. 

f. Facilities 

A full assessment will be required to determine amount of added gear and 
level of storage security required for garrison and when embarked on amphibious 
shipping. 

3. Material Alternatives Developed 

The team explored existing, new and future alternatives in a variety of 
combinations in order to evaluate the capabilities of existing communications systems 
and compare these to the functional needs of the Marine Squad. The team evaluated the 
different technical, logistical, and fiscal considerations using systems engineering 
principles and analysis. 

A ‘ Zwicky’s Morphological Box' was used as a technique to develop possible 
system alternatives. This approach encourages brainstorming at the sub-system level and 
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the subsequent combination of the brainstormed ideas in untried combinations as a way 
to produce new approaches to be vetted in feasibility screening phase of the SEDP. 

The first step in Zwicky’s process is the definition of system elements. These 
elements correspond to the functions described in our Value Model in Figure 20. These 
elements were defined as: 

■ Receive/Transmit 

■ Communication Processor 

■ Communication Generator 

■ Convey Information to User 

■ Power Supply 

The SE team then combined various combinations of functions to establish 
alternatives. Using engineering judgment, the SE team eliminated the impossible 
solutions while preserving both common and unusual combinations for comparison in 
feasibility screening. 
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Receive / 
Transmit System 

Processor 

System 

Input System 

Output System 

Power System 

FM Radio 

Software on PDA 

Keyboard 

External Earpiece / 
mic, headphones 

Rechargeable 
Lithium Ion 








Cell Phone 

Software on Laptop 

Pointer / Mouse 

Integrated Screen 

Alkaline - non 
rechargeable 










Satellite Phone 

Software on 
Cellphone 

Voice Recognition - 
CODEC 

External connection 
- Heads up display 

Solar rechargeable 
battery 







AM Radio 

Software on 
integrated 
communication 
device 

Touchpad 

Integrated speaker / 
mic 

Piezoelectric 
rechargeable battery 








Laser 






Config 1 
Config 2 

Config 3 
Config 4 


Figure 20: Morphological Box 


All configurations must 
enable user alternatives / 
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functions 


Configurations must have 
integrated power that 
meets minimum 
endurance criteria 
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4. Feasibility Screening 

The goal of the Systems Engineering design process is to come up with a single 
solution that will best meet the needs of the Marine Corps Rifle Squad Leader. Team 
Marine executed a detailed analysis of the required functionality of the squad 
communication system based on utilizing handheld radio unit(s). In addition, scenarios 
were drawn up discussing how the system will be used in a real-time operational 
environment. The SE team took all the requirements and generated a list of material 
alternatives / solutions. Often the alternatives generated may not be technologically or 
financially viable. These solutions were put through a feasibility screening process to 
help the team move towards indentifying a single hand-held radio solution that will best 
fulfill the effective needs statement outlined in section 11B3 above. 

Feasibility screening is an iterative process and is designed to give Systems 
Engineers a way to methodically eliminate solutions after the alternatives generation 
brainstorming phase that are determined to be clearly infeasible. In most cases, 
infeasibility is determined when applying the alternatives against a list of system and 
program constraints. These constraints may be performance-based, such as the radios 
need to be able to send/receive both voice and data. Oftentimes, depending on the stage 
of the program, a team may apply financial or economic constraints on the alternatives, in 
order to eliminate systems that may be just too costly to acquire. 

The nine constraints that Team Marine identified to be relevant are as follows: 

1. The overall system weight shall be lighter when compared to “status quo” 
configuration 

2. The system shall be capable of transmitting and receiving Type 1 and Type 11 
encrypted messages - (2 channels minimum) 

3. The system shall be capable of supporting world-wide spectrum supportability 
- (must support a variety of DoD frequency ranges) 

4. The system shall have the capability to support enhanced data capability 
including digital data and streaming video - (can not be voice only) 

5. The system shall have the capability to recharge power sources during mission 
operations - (charging must occur while in operation) 
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6. The system shall be capable of gracefully entering and exiting a tactical ad- 
hoc network 

7. The system shall be configurable by users below Squad Leader 

8. The system shall operate independent of commercial telecommunication 
infrastructure 

9. Range for both Line-of-Sight (LOS) and Non-Line-of-Sight (NLOS) shall be 
at least 3 km 

The team applied the Feasibility Screening Matrix Table 3 below, which identifies 
specific constraints to the alternatives, to the multiple configurations identified in Figure 
20. This activity reduced the total number of alternatives identified above to those 
practical alternatives that need further investigation and analysis. 
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Table 3: Feasibility Screening Matrix 


Operate in Military Spectrum Bands 


National Security Agency (NSA) 
certified or certifiable 


Joint Integrated Test Center (JITC) 
certified or certifiable 


JTRS SCA 2.2 compliant 


Requires no Satellite Communication 
(SATCOM) 


Independent of commercial telecom 
infrastructure 


Backwards compatible with existing 
systems until FOC 


FM Radio 
Configuration 1 


FM Radio 
Configuration 2 


Cell Phone 
Configuration 3 


Satellite Phone 
Configuration 4 
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Configurations identified above in the Morphological Box in Figure 20 are further 
subjected to operational and support criteria. A brief description of operational and 
support issues that each alternative was subjected to follows. 

a. Operational Issues: 

To best suit the user requirements, the following operational issues must 

be satisfied by each alternative in consideration. 

■ The system shall operate in accordance to standards established by 
Military Spectrum Specification, MIL-STD 449D 

■ The system shall meet all Operational Environmental specifications 
identified in MIL-STD-810F 

■ The system shall be certifiable by assessment standards as established 
by National Security Agency (NSA) 

■ The system shall be certifiable by assessment standards as established 
by the Joint Interoperability Test Command (JITC) 

■ The system shall be compliant to current Software Communication 
Architecture (SCA) standards 

■ The system shall be capable of sustaining internal power requirements 
for missions lasting no less than 8 hours 

■ The system shall operate independently of external power 

b. Support Issues: 

To best suite the user requirements in the field, the following Support 

issues must be satisfied by each alternative in consideration. 

■ The system shall be inter-operable with existing and legacy waveforms 

■ The system shall be inter-operable with existing fielded 
communications systems 

■ The system shall be hardware and software upgradeable without major 
re-engineering 

■ The system shall maximize use of existing DoD, and USMC logistical 
support elements, including software licensing, batteries, computers, 
etc. 
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■ The system shall be ergonomically designed to fit and integrate with 
existing soldier gear 

B RECOMMENDED ALTERNATIVES 


This section describes the four (4) selected alternatives based on the completion 
of the Feasibility Screening process above. Configurations #2 and #4 in Table 3 provided 
the team direction to look at specific alternatives. The operational and support issues 
were used to further refine the alternatives prior to any further analysis. Each alternative 
below has five physical sub-systems as seen in Figure 21. These five physical sub¬ 
systems are required to support the functional requirements in order achieve the desired 
operational capabilities of the Squad Leader. The five primary sub-systems are: 


■ User Input System, (microphone, touch pads, keyboards, etc) 

■ Output System, (speakers, headsets, LCD display) 

■ Processor System, (Computer Processing Unit (CPU) provides system 
configuration, position location information, executes software programs and 
executes encryption functions as required) 

■ Receiver / Transmitter (Rx/Tx) System, (Radio Frequency (RF) spectrum 
management, modulation and amplification of RF signals) 

■ Power System, (batteries or other electrical power supply) 


Receive 

Comms 


Receiver / Transmitter 
System 


Input Data 


A3 


Process 
Comms A2 


Input System 


I 


Transmit 
Comms A5 




Processor System 



Output Data 

A4 



Output System 


Power 

A6l 


Power System 


Figure 21: Key Physical Components of Alternatives 
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1. Primitive Alternative: (Status Quo) 


Type 2 
(CUI only) 



Spare power 


Hand-set 

(Receive & Transmit) 

Type 1 
(Classified up to Secret) 

Integrated Screen 

Radio Specific Keyboard 
(Unique Text Layout) 


Spare power 

Non-rechargeable during mission 
Hand Held GPS Device 


Figure 22: Primitive Alternative 


The primitive alternative is the currently fielded solution being employed by 
Marine squad leaders in training areas, school houses and in ongoing combat operations. 
Figure 22 describes the alternative by the specific components. This alternative is 
comprised of multiple items that were purchased and fielded by separate Programs of 
Record managed by Marine Corps Systems Command (MCSC). These items were not 
bought as an integrated system and are not fundamentally interoperable or meant to be 
employed together. However, the squad leaders have learned how to employ these items 
in an integrated capable system to meet minimum functionality and capability. 

Input System 

The input devices are comprised of hand-sets or internal microphones for 
voice input communications. The operator must use a simple switch to 
select which radio device they desire to communicate on. There is no data 
capability currently associated with this alternative. External and 
disconnected from the radio(s) is a handheld GPS unit that provides the 
squad leader with current position and any pre-programmed routes or way- 
points associated with anticipated and planned mission profiles. The 
squad leader must read the data from the GPS in order to communicate 
this information across the voice only circuits and must do this once on the 
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Type 1 AN/PRC 152 radio and again on the Type 2 IISR (AN/PRC-153) 
radio. 

Processor System / CPU 

There is no data processing capability associated with this alternative. The 
squad leader must process all voice traffic and must generate their 
information as a mental image. 

Power System 

There are three non-interchangeable types of batteries associated with this 
alternative. The IISR (AN/PRC-153) uses commercially procured A-cell 
batteries. The AN/PRC-152 uses military procured chargeable and one 
time use BA-5590s batteries. The GPS unit uses an internally 
rechargeable battery which has an option of using commercially procured 
C-cell batteries. 

Rx/Tx System 

There are two radios associated with this alternative that are not 
interoperable and do not share or use a common transmission spectrum. 
The IISR (AN/PRC-153) is a line-of-site radio that provides 
preprogrammed channels associated with Radio Nets for team and leader 
voice circuits. The IISR (AN/PRC-153) has a short transmission range of 
less than 3 kilometers with degraded capability in heavy vegetation and 
urban structures. The AN/PRC-152 has a longer transmission range that 
extends to 10 kilometers but is also line-of-site dependent and also 
encounters degraded capability when employed in heavy vegetation and 
urban structures. 

Output System 

There is only one headset or handset with a speaker or ear-piece for the 
operator to listen with. The operator listens to both radios simultaneously. 
Each radio has a small LCD display which also provides information to 
the user. There is currently no visible texting or video capability on either 
radio. 
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2. Current Alternative: 



This alternative is identical to the Primitive Alternative with the following exception; 
an integrated, ruggedized laptop that has an embedded military GPS receiver. This 
enhancement is currently being fielded and employed by a few select U.S. Marine squad 
leaders in training areas, and school houses. The Current Alternative (Figure 23) is 
comprised of many of the same items that were purchased and fielded by Marine Corps 
Systems Command (MCSC) for the Primitive Alternative. Again these items were not 
bought as an integrated system and are not fundamentally interoperable; however, the 
squad leaders have learned to employ these items in the field to meet operational needs. 

Input System 

The input devices are comprised of hand-sets or internal microphones for 
voice input communications, and a ruggedized laptop to input and receive 
data communications. Integrated into the laptop is an embedded GPS unit 
that provides the squad leader with current position and any pre¬ 
programmed routes or way-points associated with anticipated and planned 
mission profiles. 
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Processor System / CPU 

The ruggedized laptop provides minimal computing capability to convey 
and display unit level C2/SA. The laptop is configured with military and 
commercial software offering limited data capability to the squad leader. 

Power System 

There are three non-interchangeable types of batteries associated with this 
alternative. The IISR (AN/PRC-153) uses commercially procured A-cell 
batteries. The AN/PRC-152 uses military procured chargeable and one 
time use BA-5590s. The laptop unit uses an internally rechargeable 
battery with option of using externally generated DC power. 

Rx/Tx System 

There are two radios associated with this alternative that are not 
interoperable and do not share or use a common transmission spectrum. 
The IISR (AN/PRC-153) is a line-of-site radio that provides 
preprogrammed channels associated with Radio Nets for team and leader 
voice circuits. The IISR (AN/PRC-153) has a short transmission range of 
less than 3 kilometers with degraded capability in heavy vegetation and 
urban structures. The AN/PRC-152 has a longer transmission range that 
extends to 10 kilometers but is line-of-site dependent and also encounters 
degraded capability when employed in heavy vegetation and urban 
structures. 

Output System 

There is a cable required to connect the laptop to the AN/PRC-152. This 
cable is made specifically for this radio and is proprietary to this 
employment option. 
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3. Advanced Alternative: 



Figure 24: Advanced Alternative 


This alternative is a first attempt at providing the squad leader with a fully 
integrated system comprised of wearable and hand-held sub-systems. This design is 
being evaluated by PM Soldier for the Ground Soldier Ensemble (GSE). It offers user 
tailorable allowing for each squad leader or unit to determine best mix of capability. The 
Advanced Alternative (Figure 24) is currently being evaluated by the Army and select 
Marine Corps units for consideration. Previous prototype designs of this alternative have 
been employed by soldiers in operations in Iraq and are currently being employed in both 
Iraq and Afghanistan. 

Input System 


The input devices are comprised of hand-sets or internal microphones for 
voice input communications, and user specified data input devices. 
Several alternative data input devices are being evaluated to include 
“gameboy” controllers, touch-screens, hand-held mouse assembly units, 
and wearable keypads. Integrated into the system is an embedded GPS 
unit that provides the squad leader with current position and any pre- 
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programmed routes or way-points associated with anticipated and planned 
mission profdes. 

Processor System / CPU 

The wearable computer provides advanced computing capability to 
convey and display unit level C2/SA. It is configured with military and 
commercial software offering enhanced data capability to the squad 
leader. 

Power System 

There are two non-interchangeable types of batteries associated with this 
alternative. The Rifleman Radio (RR) uses military procured chargeable 
and one time use BA-5590s. The wearable backpack system uses an 
internally rechargeable battery with option of using externally generated 
DC power. 

Rx/Tx System 

There are two radios associated with this alternative that are interoperable 
and do not share or use a common transmission spectrum. Due to the two 
classification levels, the RR via a data-diode injects individual Position 
Location Information (PLI) into the fully operable data processing unit 
worn by the squad leader. The radios are line-of-site radios that provide 
preprogrammed channels associated with Radio Nets for team and leader 
voice and data circuits. They are line-of-site dependent and are effective 
for ranges of 10-15 kilometers and also encounter degraded capability 
when employed in heavy vegetation and urban structures. The radios 
provided through the Joint Tactical Radio System (JTRS) bring enhanced 
capability by providing meshing and ad-hoc networking. 

Output System 

The cable assembly is integrated into the wearable system with the ability 
to use external cables for user specific employment options. 
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4. Future Alternative: 



Figure 25: Future Alternative 

This alternative is only a concept at this point as only a few components are 
commercially available, while many others are currently under Research and 
Development today. The Future Alternative (Figure 25) represents a fully integrated 
system, with a complete evaluation of human factors. 

Input System 

The input devices should be tailorable and provide user input associated 
with “I-touch” like capability. 

Processor System / CPU 

The wearable computer should provide advanced computing capability to 
convey and display unit level C2/SA. It is configured with military and 
commercial software offering enhanced data capability to the squad 
leader. 
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Power System 

The power supply should seek alternative power generation alternatives - 
one example is the piezoelectric powered insoles pictured above. 

Rx/Tx System 

The radio provided through the Joint Tactical Radio System (JTRS) or 
other programs must provide integrated, multi-level security into a single 
device with enhanced capability by providing meshing and ad-hoc 
networking. 

Output System 

The output system must be compatible with night vision displays or 
goggles. This design should seek to minimize cables and use wireless 
alternative options to “tie” the devices together - much like Bluetooth 
does for headsets and cell phones. 

C MODELING AND SIMULATION 

1. Tools and Approach 

The Squad Communication System model was developed using Arena 10.0 student 
version. Arena is a modeling and simulation tool produced by Rockwell Automation to 
provide the user with alternative and interchangeable templates of graphical simulation 
modeling and analysis modules that can be graphically combined to mathematically 
model and simulate systems for detailed analysis of the system. (Kelton, Sadowski, 
Sturrock, 2007). The model represents a Marine Corps Squad Leader’s ability to receive, 
generate, and process communication messages. The model measures the workload 
associated within a typical squad employment scenario and measures the ability of a of 
the squad leader to communicate with higher headquarters and the squad fire teams. The 
Squad Communication model is a queuing model to mimic workload capacity of a 
Marine Corps Squad Leader. 

a. Workload Methodology 

The workload methodology for modeling human performance is based on the 
multiple resource theory for discrete events originally developed by Wickens (1984). 
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Wickens described work load as total demand placed on human as he/she performs a task 
(as cited by Keller, 2002). Workload could thus be described as the total demand placed 
on the Squad Leader as he/she performs a task. In Multiple Resource Theory, workload 
is not just the result of one central processing resource but the use of several processing 
resources or workload channels. The multiple resources are described as visual, auditory, 
cognitive and psychomotor. Rating scales for each of these resources were developed to 
describe the workload required to do generic tasks or anchoring statements. The rating 
scales in Figure 2 were originally developed based on work by McCrasken & Aldrich 
(1984) and Bierbaum, Sxabo & Aldrich (1987). However the rating scales updated in 
2000 by the Army Research Laboratory (Mitchell, D.K. 2000) and used in the task 
analysis for performing the system communication functions. 
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Table 4: Simulation Descriptors and Scale Values 


Descriptors 

Scale 

Value 

Visually 


Visually register or detect (detect occurrence of image) 

3.0 

Visually inspect or check (discrete inspection or static condition) 

3.0 

Visually locate or align (selective orientation) 

4.0 

Visually track or follow (maintain orientation) 

4.4 

Visually discriminate (detect visual differences) 

5.0 

Visually read (symbol) 

5.0 

Visually scan or search monitor (continuous or serial inspection, multiple conditions) 

6.0 

Auditory 


Detect or register sound (detect occurrence of sound) 

1.0 

Orient to sound (general orientation or attention) 

2.0 

Orient to sound (selective orientation or attention) 

4.2 

Verify auditory feedback (detect occurrence of anticipated sound) 

4.3 

Interpret semantic content (speech) simple (1 to 2 words) complex sentences 

3.0 

Interpret semantic content (speech) complex sentences 

6.0 

Discriminate sound characteristics (detect auditory difference) 

6.6 

Interpret sound patterns (pulse rates, etc) 

7.0 

Cognitive 


Automatic (simple association) 

1.0 

Alternative selection 

1.2 

Sign or Signal recognition 

3.7 

Evaluation or judgment (consider single aspect) 

4.6 

Rehearsal 

5.0 

Encoding or decoding, recall 

5.3 

Evaluation or judgment 

6.8 

Estimation, calculation, conversion 

6.8 

Psychomotor 


Speech 


Speech simple (1 to 2 words) 

2.0 

Complex (sentence) 

4.0 

Motor 


Discrete actuation (button, toggle, trigger) 

2.2 

Continuous adjustive (flight control, sensor control) 

2.6 

Manipulative 

4.6 

Discrete adjustment (rotary, vertical thumb wheel, lever position) 

5.5 

Symbolic production (writing) 

6.5 

Serial discrete manipulation (keyboard entries) 

7.0 


b. Communication Messages Task Analysis 

The functions were taken directly from the Functional Analysis and further 
decomposed into specific human tasks for operating the four alternatives defined earlier 
in the system engineering methodology. The generic tasks associated with each function 
were further defined from the alternatives and given a scale value. This task analysis and 
assignment of value is limited in scope for this project and has evolved as a mental 
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exercise in performing the tasks. Further analysis should include alternative mock-ups, 
testing with actual users, and completed surveys to better understand the intricacies of the 
alternatives. This conceptual analysis will help to determine qualitative differences in 
levels of workload required to send and receive communication messages. The limited 
scope task analysis is referenced below: 

Receive Communication Information: 

1. No Human tasks for any alternative 
Process Automated GPS:* 

1. Toggle GPS buttons Read GPS (Voice only) 

2. Read GPS data (Voice only) 

3. Evaluate GPS data (Voice only) 

Note: * Data - No Human tasks for any alternative 
Process Communication Information: - Send 

1. Physically change radios (if two radio solutions are used) 

2. Gather information to be sent: Recall voice information if transferred 
from radio or retrieve stored data 

3. Verbalize information into hand microphone -or- voice recognition 
device -or- input via a keyboard 

Process Communication Information: - Receive: 

1. No Human tasks for any alternative 
Transmit Communication Information: - Send 

1. Toggle send key -or- push send key -or- verbally send via voice 
recognition device. 

Convey Information to User 

1. Physically move handset to ear -or- open screen -or- move screen into 
view. 

2. Listen to message or read message 

3. Write down required information (voice only) 

4. Evaluate information 

c. Simulation Model Part Descriptions 
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Overall Simulation Process: The Arena model will model the communications 
process using discrete events, taking a message through the entire communications 
process over time steps and measuring Squad Leader workload. The model will process 
receiving or sending message as a delay, release, and by assigning a workload attribute 
process. These parameters will be established based on the individual solutions in the 
system alternatives. 

Entity Generators: Each message required for the simulation for both generated 
and received messages is controlled by a entity generator. Each message generator 
introduces a communication message (entity) to the squad leader in order to process a 
receive message or generate an outgoing message. This entity will have attributes that 
describe the message and be used in the processing sub-models within the overall model 

Entities Attributes: An attribute is a common characteristic of all the entities, 
but specific values can differ from the other entities. (Kelton, Sadowski & Sturrock, 
2007). Each message has two levels of attributes 1) Message Descriptions and 2) 
Workload Descriptions assigned and used in the simulation. 

1. Message Descriptions Attributes: 

Data Message: - if 1, then this message is a data only message; if 0, this message 
is a voice only message 

Generate Message: - if 1, then this is a message that needs to be generated; if 0, 
this is received message 

Need GPS: - if 1, then this generated message needs GPS coordinates; if 0, this 
message does not need GPS coordinates. 

Lines in Message: - the number of lines in the message to convey sufficient 
information. 

Renege Time: - the max time the message is still relevant to the squad leader. 
Once the renege time is reached, the model will pull the entity from the queue and 
free up the workload resource. 

2. Workload Descriptions Attributes: 
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Visual, Auditory, Cognitive, and Psvchomotor Workload - Assigned a rating of 1 
- 7 for each functional task to the system global variable as it passes through each 
of the alternatives. Scale values and descriptors for each of the resources are in 
below. 

Total Workload - Total workload is sum of the resources for that specific 
functional task. 

Global Variables: Global variables are information that reflects a characteristic of 
the system regardless of the types or quantity of entities in the simulation (Kelton, 
Sadowski & Sturrock, 2007). Variables are used in the simulation to track the workloads 
within the system. The workload description attributes described in the entity attributes 
work together to ensure the system properly disposes workload after the entity is 
processed. Global variables include total workload, visual workload, auditory workload, 
cognitive workload, psychomotor workload, and time in the system. 

Queue: A queue is used to model the squad leader’s ability to seize a workload 
resource as described by the entity workload description attributes. The queue provides 
the gate for the message to be sent or received without over taxing the squad leader 
ability to process that message (send or receive). The Communication Processing Queue 
will attempt to process Communication Messages (Entities) until it meets a max threshold 
of total workload, visual workload, auditory workload, cognitive workload, or 
psychomotor workload. 

Resource: Once an entity reaches the queue, a resource must be pulled in order to 
process the message. The resource for the simulation is the max total workloads, max 
visual workload, max auditory workload, max cognitive workload, or max psychomotor 
workload. The lower the required resource, the more efficient the system alternative 
performed. 
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Table 5: Primitive Alternative Recorded Parameters 


Primitive 


Human Process Time (per 
line in message or per GPS 
entry)(sec) 

[Triangular Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive Communication 

Information 

Voice 


0 

0 

0 

0 

0 










Process Automated GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 









Process Commo InfoSend 

Voice 

(8,10,12) 


0 

5.3 


4.6 

13.9 

Transmit Commo Info Send 

Voice 

_ 


0 

0 


2.2 

2.2 

Process Commo InfoReceive 

Voice 

(8,10,12) 

^■a 

0 

0 


6.5 

6.5 

Convey Information to User 

Voice 


IS1 


5.3 

0 

2.2 

13.5 
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Table 6 Current Alternative Recorded Parameters 


Current 


Human Process Time 
(per line in message or 
per GPS entry)(sec) 
[Triangular Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive Communication Information 

Voice 


0 

0 

0 

0 

0 

0 

Data 


0 

0 

0 

0 

0 

0 

Process Automated GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process Commo InfoSend 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

4.6 

13.9 

Data 

(15,25,35) 

0 

0 

1 

0 

7 

8 

Transmit Commo Info Send 

Voice 


0 

0 

0 

0 

2.2 

2.2 

Data 


0 

0 

0 

0 

2.2 

2.2 

Process Commo InfoReceive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey Information to User 

Voice 


0 

6 

5.3 

0 

0 

11.3 

Data 


5 

0 

4.6 

0 

4.6 

14.2 
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Table 7: Advanced Alternative Recorded Parameters 


Advanced 


Human Process Time 
(per line in message or 
per GPS entry)(sec) 
[Triangular Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive Communication Information 

Voice 


0 

0 

0 

0 

0 

0 

Data 


0 

0 

0 

0 

0 

0 

Process Automated GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process Commo Info Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

0 

9.3 

Data 

(20,30,40) 

3 

0 

1 

0 

2.2 

6.2 

Transmit Commo Info Send 

Voice 


0 

0 

0 

0 

2.2 

2.2 

Data 


0 

0 

0 

0 

2.2 

2.2 

Process Commo Info Receive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey Information to User 

Voice 


0 

6 

5.3 

0 

0 

11.3 

Data 


5 

0 

1 

0 

2.2 

8.2 
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Table 8: Future Alternative Recorded Parameters 


Future 


Human Process Time 
(per line in message 
or per GPS 
entry)(sec) 
[Triangular 
Distribution] 

Workload 

Total 

Visual 

Auditory 

Cognitive 

Psychomotor 

Speech 

Motor 

Receive Communication Information 

Voice 


0 

0 

0 

0 

0 

0 

Data 


0 

0 

0 

0 

0 

0 

Process Automated GPS 

Voice 

(10,15,20) 

3 

6 

4.6 

4 

2.2 

19.8 

Data 

(3,5,8) 

0 

0 

0 

0 

0 

0 

Process Commo Info Send 

Voice 

(8,10,12) 

0 

0 

5.3 

4 

0 

9.3 

Data 

(10,15,18) 

1 

0 

1.2 

4 

0 

6.2 

Transmit Commo Info Send 

Voice 


0 

0 

0 

0 

2.2 

2.2 

Data 


0 

0 

0 

2 

0 

2 

Process Commo Info Receive 

Voice 

(8,10,12) 

0 

0 

0 

0 

6.5 

6.5 

Data 

(1,2,3) 

0 

0 

0 

0 

0 

0 

Convey Information to User 

Voice 


0 

6 

5.3 

0 

0 

11.3 

Data 


5 

0 

1 

0 

0 

6 
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d. System Evaluation Simulations 

As discussed previously, the purpose of the simulation was to measure workload on 
the Squad Leader during an operational scenario using the various alternatives. The 
simulation will compare the number of messages processed to the total messages sent or 
received through a given scenario and the amount of workload capacity required. The 
model will provide the following inputs in to the analysis of alternatives functions: 


Table 9: Analysis of Alternative Function Simulation Output 


A2 Process Communications Information 


A22 Process Incoming Communication Messages 



% Processed Incoming Messages 


A22 Process Outgoing Communication Messages 



% Processed Outgoing Messages 

N5 Ensure Usability & Human Factors 


N55: Ability & Complexity to Consume Analog & Digital Data 



Max Total Workload 


e. Model Input/Output 

There are three primary modules requiring inputs in order to define the 
system alternatives and the scenario. The first inputs are the scenario message 
generators. The message generators were held constant for all simulation of the 
alternatives. This ensured the simulation consistently sent the same number of 
messages in relatively same amount of time. The second inputs were the attributes 
of these messages. The messages varied slightly depending on the capability of the 
alternative to process data and voice messages. For all alternatives, except for the 
primitive alternative, there was a mixture of voice and data messages. For the 
primitive alternative, there were no data messages generated due to the lack of data 
capability. The input values for the scenarios generators and message attributes are 

located in Table 10, Table 11, and 
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Table 12. As the messages are being processed by the system, multiple variables 
and attributes were assigned to define the workload required to process a message. The 
workload attributes and variables are the third and final inputs to the simulation. These 
inputs varied with the workloads required to perform the human tasks of processing 
communication messages for the system alternatives. These variables and attributes are 
used in the queuing process of the model. The output of the simulation helped define 
ranking of the alternatives and the ability of the squad leader to process those messages. 
The processing attributes are defined in Table 5, Table 6, Table 7, and Table 8. 

Input Values: 

1. Messages sent and received by the squad leader include (Table 12, 13, 14) 

a. Number of lines of communications in each message 

b. Start time and frequency the message is sent or received 

c. Number of that specific type of message is sent or received. 

d. Max number of that specific type of message is sent or received during 
the scenario 

e. The estimated max time the message becomes irrelevant to the squad 
leader and is used as reneging time within the model. 

2. Workload for each Functional Task (Table 7, 8, 9, 10) 

a. Human Process Time per line of the message or per GPS entry into the 
message. 

b. Workload for each resource and total workload for each functional task. 

Workload will be measured in workload units. 

Output Values: 

1. # of communication messages processed 

2. # of communication messages reneged 

3. Average time to process messages 

f. Model Description 
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The model has a main view that consists of the message generators, the message 
attribute assignment module, the system functional processing sub-model and the 
disposal module. The system functional processing model consists of data message 
processing sub-model, voice message process sub-model, the model queuing sub-module, 
and a reneging sub-module. The process data message and process voice message sub¬ 
models contain the same functions as described by the system functional architecture, but 
varies with workloads of processing voice or data messages. 

2. Situation 

The patrol is operating out of a company FOB in a third-world urban city. The 
FOB is well situated but has several insurgents and unfriendly personnel in the vicinity. 
The patrol is assessing a street corridor to determine level of hostile activity and threat 
associated with occupying forces. The patrol has complete conductivity with appropriate 
units as outlined in the operational architecture. This includes communications to the fire 
teams in the squad for order execution. 

The scenario will only focus on the squad leader’s ability to process 
communication in a patrol with 3 fire teams. 

Patrol Scenario taken from the Operational Activity Model (OV-5) of the Marine 
Expeditionary Rifle Squad (MERS) Architecture. (MERS Architecture Final Practicum 
Project Report, June 2008). The scenario simulates a MERS Combat Operation and 
begins after completion of the Plan Patrol activity during the Conduct Patrol activity. 
The Execute Route command has been given and the maneuver squad is moving along 
designated route based on the predefined lat/long coordinates. 



o 





) Fire 
Team 1 


Enemy 



Conduct Patrol 



Consolidate 


Fire 

Team 3 


O 


Squad JL 
Leader VX 
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Figure 26: Simulated Scenario Model 

Fire Teams will report position location information and situation updates 
throughout the mission. The patrol will come in contact with the enemy along the route. 
The enemy is a small insurgent unit intent on disrupting the patrol movement along the 
route. Upon contact, the patrol will return fire and call in artillery fire from the supporting 
artillery battery located in a nearby forward operating base. Upon suppression of the 
enemy unit with direct and indirect fire, the patrol will assault the enemy position. When 
the enemy unit is destroyed, the patrol will consolidate and request causality evacuations. 
Assumptions: 

• No voice or data message confirmations will be modeled (ie. “Roger”, “WILCO”, 
etc) 

• Voice or data only messages. Hybrid messages are not modeled. 

a. Phase 1 

Conduct Patrol - The patrol will move along designated routes outlined in the pre¬ 
determined plan. The Squad Leader will continually communicate current position and 
location to the platoon leader and synchronize command and control of fire teams during 
movement. Table 10 defines the inputs to the simulation for phase 1. 

b. Phase 2 

Engage Enemy - The patrol taking small arms fire from a group of insurgents in urban 
terrain. The squad employs personal weapons for effective squad protection then requests 
Fire Support to suppress the enemy. Once the enemy is suppressed, the patrol assaults 
the enemy position to destroy remaining combatants. Table 11 defines the inputs to the 
simulation for phase 2. 

c. Phase 3 

Consolidate Position - The patrol establishes a secure boundary to repel a counter 
attack. One team has a casualty and requests a MEDEVAC for a wounded squad 
member. Table 12 the inputs to the simulation for phase 3. 
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Table 10: Phase 1 Simulation Events 


From 

To 

Message 

Type 

Lines in 
Message 

Start 

Time 

(min) 

Frequency 

#of 

Entities 

Max# 

Renege 

Time 

(sec) 

FT 

SQD LDR 

FT Geographic Position 

l 

l 

30 

TRIA(18,20,22) 

1 

3 

180 

SQD LDR 

HQ 

SQD Geographic Position / 

Friendly Location 

ll 

4 

35 

TRIA(20,30,40) 

1 

3 

1200 

FT 

SQD LDR 

FT Situation Update_Patrol 

l 

2 

60 

TRIA(15,20,25) 

l 

3 

420 

SQD LDR 

HQ 

SQD Situation Update_Patrol 

ll 

2 

65 

TRIA(20,30,40) 

1 

3 

1200 

SQD LDR 

FT 

SQD Tactical Commands _Patrol 
(voice only) 

l 

1 

0 

TRIA(18,20,22) 

1 

5 

60 
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Table 11: Phase 2 Simulation Events 


From 

To 

Message 

Type 

Lines in 
Message 

Start 

Time 

(min) 

Frequency 

#of 

Entities 

Max# 

Renege 

Time 

(sec) 

FT 

SQD LDR 

FT Enemy Location Report 

l 

3 

120 

Once 

1 

l 

180 

SQD LDR 

FT 

SQD Terminal Weapons 
Guidance_Engage 

l 

3 

121 

Once 

1 

l 

180 

SQD LDR 

HQ 

SQD Enemy Locations 

ll 

2 

123 

Once 

1 

l 

1200 

SQD LDR 

HQ 

SQD Situation Update_Engage 

ll 

2 

130 

TRIA(8,10,12) 

l 

4 

1200 

FT 

SQD LDR 

FT Call for Fire 

ll 

5 

144 

Once 

l 

1 

420 

SQD 

HQ 

SQD Call for Fire 

l 

5 

150 

Once 

l 

1 

420 

HQ 

SQD 

Fire Notification 

l 

1 

160 

Once 

l 

1 

60 

SQD 

FT 

SQD Fire Notification 

ll 

1 

166 

Once 

l 

1 

60 

SQD LDR 

FT 

SQD Tactical Commands_Assault 
(voice only) 

l 

1 

180 

Once 

l 

1 

60 


- 80 - 



Table 12: Phase 3 Simulation Events 


From 

To 

Message 

Type 

Lines in 
Message 

Start 

Time 

(min) 

Frequency 

# of 

Entities 

Max# 

Renege 

Time 

(min) 

SQD LDR 

FT 

SQD Tactical Commands_Secure 
(voice only) 

1 

1 

200 

TRIA(4,5,10) 

1 

4 

60 

SQD LDR 

FT 

SQD Terminal Weapons 
Guidance_Secure 

1 

3 

220 

Once 

1 

1 

60 

FT 

SQD LDR 

FT MEDEVAC Request 

1 

3 

230 

Once 

1 

1 

180 

SQD LDR 

HQ 

SQD MEDEVAC Request 

II 

3 

232 

Once 

1 

1 

180 

FT 

SQD LDR 

FT_Causality Report 

1 

4 

240 

Once 

1 

1 

420 

SQD LDR 

HQ 

SQD Members Health 

II 

4 

250 

Once 

1 

1 

1200 
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3. Results 

Based on the described simulation inputs, the results are shown in Table 13. The 
Current, Advanced, and Future processed the same percentages of incoming (received) 
and outgoing (generated) messages with 45% and 30% respectively. Although they were 
able to process the same percentages of messages, the Future was the only alternative 
able to perform this without violating the workload threshold of 8.0 workload units as 
defined by Multiple Resource Theory by Wickens (1984). The Advanced followed just 
short of the threshold value with 8.5 workload units. The Current and Primitive required 
81% and 150% more workload capacity of the squad leader to stay within the range of 
the threshold workload value. In addition a high max total workload, the Primitive 
alternative could not process outgoing (generated) messages as efficiently as the other 
three alternatives with only 19% of processed outgoing messages processed. 


Table 13: Simulation Results 



Primitive 

Current 

Advanced 

Future 

% Processed 

Incoming 

Messages 

10/22 = 

45% 

10/22 = 

45% 

10/22 = 

45% 

10/22 = 

45% 

% Processed 

Outgoing 

Messages 

10/52 = 

19% 

16/52 = 

30% 

16/52 = 

30% 

16/52 = 

30% 

Max Total 

Workload 

20.0 

14.5 

8.5 

6.5 


4. Model Limitations and Sensitivity 

As with most models and simulations, accurate input data must be verify and 

validated with the results. Because this was a qualitative assessment of the different 

alternatives using a specific workload theory, not all results are sufficient to predict actual 

performance but provide a benchmark for comparison. The workload values have a 

particular sensitivity to the outcome of the simulation. Actual testing should be 

conducted on prototype devices with a sample size of actual users that can normalize the 

workload values of the different alternatives. This would lead to statistical variations in 

the workload values rather than using discrete values bound by anchor statements from 

previous human factor studies. Although the model has these limitations as described 

above, the level of confidence in the qualitative assessment of the alternatives is strong 
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enough to be used in the decision matrix and be evaluated for the sensitivity of the overall 
outcome of the recommended alternative. 

D ALTERNATIVES SCORING 

After the modeling and simulation analysis was completed, the team used the 
remaining weighting factors as criteria to further analyze the four recommended 
alternatives. This section describes the analysis completed for the system weight, power 
duration, usability and reliability. 

1. Physical Weight Analysis 

The physical weight of the communications system is extremely important to the 
person who must carry the system into battle. War-fighters have been known to saw off 
the end of their toothbrushes to reduce the weight so that they can carry more food and 
ammunition. Therefore the users hold physical weight to be of significant interest. The 
less weight the better. For that reason physical weight has a significant weighting factor. 
To determine the raw weight score for the four alternatives the components weights were 
added to determine an overall system weight. The total system weight for each 
alternative is displayed in Table 14 below. The actual components of each alternative are 
shown in Figure 22 through Figure 25 and are listed in Table 17 and Table 18. When the 
four alternatives are compared it should be noted that the future system combined weight 
is much less than the other systems. This is because the future system takes advantage of 
internal circuitry and weight reducing materials. The other three alternatives are very 
close in weight. When scoring the four alternatives the future system is ranked first. 


Table 14: Physical Weight comparison 



Primitive 

Current 

Advanced 

Future 

Total Physical 
Weight 

13 pounds 

13.8 pounds 

12.6 pounds 

5.7 pounds 


2. Power Duration (Battery Life) Analysis 

A close second in importance to the user is the battery life of the system. The 
system must supply sufficient power to the system to permit effective communication or 
the system is of little use to the war-fighter. Work continues to provide a rechargeable 
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power source in the field, however, at this time no reliable rechargeable source is on the 
horizon. Therefore internal and replaceable batteries will be used for the foreseeable 
future. As can be seen from Table 15 below, battery life technology produces similar life 
for all four alternatives; however, the future system has a power regeneration component 
and thus can extend the total duration time for a much longer period. To determine the 
battery life the shortest battery life in the system was used as the defining raw score for 
the system. The future system again is ranked first. 


Table 15: Power Duration comparison 



Primitive 

Current 

Advanced 

Future 

Power Duration 
= Battery life 

6.5 hours 

8 hours 

8.5 hours 

>10 hours 


3. Usability Analysis 

The usability analysis was an overall look at each system as a whole using a 
Likert Scale (1-7) where seven represents the system that is easiest to use. Eleven 
participants conducted a paper evaluation on the overall ease of use for each of the four 
alternatives. Statistical analysis was performed on the surveys and the median scores are 
presented in Table 16. 


Table 16: Ease of Use Comparison 



Primitive 

Current 

Advanced 

Future 

Likert Score 

4.5 

5.0 

6.0 

7.0 


4. Reliability Analysis 

Reliability was selected as a quantitative measure to aid the team in decision 
making. The primary physical elements of the communications system for each 
alternative were defined and evaluated. Table 17 below shows each of the key 
components and their corresponding Reliability data. Data was captured via 
manufacturer printed material as well as market research on commercially available 
components. Though specific products or manufacturers declare unique Mean Time 
Between Failure (MTBF) values, there is enough testing and documented literature to 

provide essential trends for various products. 
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Each component’s Reliability value (R-value) was calculated by using the 
reliability equations from Sage & Armstrong [4] below. 

A= 1/ [J 

Where /v is the MTBF and 
R(t) = e - M 
Where t is time 


The minimum mission duration for the squad is approximately eight hours, and 
thus, eight was the value used for t in all calculations. 


The R-value equations for systems in serial and parallel configurations, (Figure 27 
and Figure 28 respectively) are given below: 


Input 



Output 



R c 


Figure 27: Serial Reliability Equation 


Input 


Component 

A 


Component 

B 


Component 

C 


Output 


R total = 1-(1-R A )*(1 -R b )*( 1-R c ) 


Figure 28: Parallel Reliability Equation 

The exact configuration of each alternative and the components used in each 
alternative defined the equations used which are also annotated in Table 17 below. 
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Table 17: Reliability Values - Components and Alternatives 



MISSION DURATION 

t = 

8.00 

hours 


Component 


MTBF 

= mu 

lambda = 
1/mu 

R-value = e A 
(-lambda*t) 

A 

BATTERY POWER 


250 

0.004000 

0.96851 

B 

HEADSET/MIC 


3900 

0.000256 

0.99795 

C 

LCD DISPLAY /SCREEN 


50000 

0.000020 

0.99984 

D 

RADIO (Rx/Tx) 


10000 

0.000100 

0.99920 

E 

KEYPADS 


20000 

0.000050 

0.99960 

F 

COMMS PROCESSOR 


10000 

0.000100 

0.99920 

G 

GPS UNIT 


15000 

0.000067 

0.99947 

H 

HUMAN 


2000 

0.000500 

0.99601 

1 

PIEZO ELECTRIC POWER 


20000 

0.000050 

0.99960 


Alternative Components 


Alternative 

R-Value 


a*d*b*h 


PRIMITIVE 

0.96189 


A*(1-(1-B)(1-E))*D*(1-(1-B)(1-C))*H 


CURRENT 


0.96387 


A*(1-(1-B)(1-E))*D*F*G*(1-(1-B)(1- 

C))*H 


ADVANCED 


0.96258 


l*(l-(l-B)(l-E)) *D*F*G*(1-(1-B)(1-C))*H FUTURE 


0.99481 


Each alternative has a total system R-value based on the physical components 
used and their respective individual R-values, as well as the component layout, (serial, 
parallel or combinations of both). The total R-values for each alternative is provided in 
Table 17 above. It can be shown quantitatively that the Future Alternative has the highest 
total system reliability value (99.48% of an 8 hour mission). 
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E COST ANALYSIS 


The methods described above develop a single utility value or score for each 
alternative that could be used to select the reco mm ended alternative. However, doing so 
would be premature. Total utility is not the only important criterion left with which to 
judge the possible solutions. Each of the four alternatives is deemed feasible. These 
alternatives are further analyzed to determine level of added capability provided and at 
what cost in section IVD. The objective is to assess the Return on Investment. 

1. Acquisition Costs 

The cost of each alternative must be addressed. The cost is examined relative to 
Acquisition and Operations and Support (O&S) Cost. Each alternative may have 
significantly different costs which affect the decision as to which alternative should be 
pursued. It is not this team’s job to make the final decision but to provide the 
stakeholders with a recommendation and the information they need to make intelligent 
decisions. 

Each alternative is composed of a set of components. Some components are used 
in more than one alternative, but each alternative is unique. Most of the components are 
initially purchased from existing programs of record. 

Spreadsheets were used to capture component data and to analyze both 
mathematically and graphically the relationships and relative costs between alternatives. 
In order to generate a cost estimate for a single alternative, the cumulative costs of the 
components were determined or estimated based on cost analysis 
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Table 18: System Components for Each Alternative 


Primitive Alt 

Current Alt 

Advanced Alt 

Future Alt 

PRC 152 
(ECO pg 26) 

PRC 152 
(ECO pg 26) 

PRC 154 
(EDM) Incr 1 
(RR CPD pg 4) 

PRC 154 
(EDM) Incr 2 
(RR CPD pg 4) 

PRC 153 
(ECO pg 19) 

PRC 153 
(ECO pg 19) 

PRC 153 
(ECO pg 19) 


Headsets 

(included with radio) 

Headsets 

(included with radio) 


Heads Up Display 4 
Internal Earpiece 5 

Handheld GPS 
(ECO pg 23) 

Laptop (MR-1) 
(embedded GPS) 
(ECO pg 29) 

Touch Pad 2 


GPS Battery 

Laptop Battery 1 

Touch Pad Battery 2 


Radio Battery 4 

Radio Battery 4 

Radio Battery 4 

Piezo-electric Power 


1 http://www.laptopbattervdepot.com/shopping/productdetails.asp 

2 sales@glaciercomputer.com 

3 http://www.myshopping.com 
4 http://www.buchmann.ca/article20-page 1 .asp 

5 http://customearpiece.com/category.php?id=18&gclid=CN71y7aA5pwCFRkpawodp08gFQ 

The costs are derived from both parametric cost analysis based on subject matter 
expert inputs and actual costs based on published documentation from respective 
programs while other costs were obtained through internet research. SMEs provided unit 
prices, system specifications (including size, weight and power data used in other 
sections of this paper), and capability estimates based on current systems of record. The 
SMEs were able to provide a rough estimate when actual cost data for the respective 
system was unavailable. Unknown variables such as integration costs were given best 
effort analyses to determine reasonable cost ranges. 

The costs for each of the alternatives, broken down by components and compiled 
into an acquisition cost, are displayed in Figure 29 through Figure 32. 
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Primitive Alternative Component Costs 
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Figure 29: Primitive Alternative Component Costs 


Current Alternative Component Costs 
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Figure 30: Current Alternative Component Costs 
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Advanced Alternative Component Costs 
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Figure 31: Advanced Alternative Component Costs 


Future Alternative Component Costs 
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Figure 32: Future Alternative Component Costs 
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The acquisition costs totals for each alternative, as compared to the other 
alternatives, are shown in Figure 33. 

Acquisition Cost Comparison 


40000 

35000 

30000 

25000 

| 20000 
o 

15000 

10000 

5000 

0 


Figure 33: Acquisition Cost by Alternative 

2. Operations and Sustainment Costs 

“O&S has historically been the largest portion of Life Cycle Cost. A complete 
estimate of O&S costs will typically include the costs of personnel, consumables, goods 
and services, and sustaining support and investments associated with the peacetime 
operation of a weapon system. Operating and support costs normally constitute a major 
portion of system life- cycle costs and, therefore, are critical to the evaluation of 
acquisition alternatives.” (Defense Technical Information Center, 1992). The Rifleman 
Radio CPD supports this data and states that the AN/PRC-154, which provides a major 
portion of functionality for the Advanced and Future Alternatives, has O&S costs that are 
65% of the Total Life Cycle costs. 

The O&S costs for the hardware are shown in Figure 34 and are based upon the 
three to five year hardware replacement standard and the software upgrade standard every 

12 to 18 months. The normal radio replacement plan is a 7-10 year cycle. The O&S 
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costs were estimated for a ten year period. All of these facts are taken into consideration 
in determining the O&S costs for the alternatives that include the AN/PRC-154 as a 
component. The O&S costs are further extrapolated to the other alternatives based on the 
similarity of the systems. 

O&S Cost Comparison 



Alternatives 

Figure 34: Operational and Supportability Costs 

The Rifleman Radio CPD presents O&S as the largest cost contributor in the PRC 
154 Total Life Cycle costs. The O&S costs for the hardware are based upon the 
maximum of the three to five year replacement standard and the software on an 18 month 
replacement standard. The normal radio replacement plan is a 7-10 year cycle. The 
fielding schedule for PRC 154 is FY11-18. Additional replacement or upgrade fielding is 
planned at the end of the AN/PRC-154 lifecycle. 

3. Total Life Cycle Costs 

The Total Life Cycle Costs, as defined for the purposes of this project, are the 
combination of the Acquisition and O&S costs as shown in Figure 35. 
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Total Life Cycle Cost Comparison 
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Figure 35: Total Life Cycle Costs 

The Primitive, Current and Advanced alternatives costs all fall within a $2300 
range. The Future alternative cost is between three and four times as much as the others. 


F ALTERNATIVES SCORING RESULTS AND SUMMARY 


After the execution of the SE process, the modeling and simulation, capturing 
system data and evaluating the results from all of the analysis efforts described above, the 
teams final effort was completing the Decision Analysis process. The team was prepared 
to make a recommendation for a specific alternative and COA, based on the quantitative 
data shown in Table 19. It is clear from the Capability vs. Cost mappings in Figure 36 
that the best “bang for the buck” is the Advanced Alternative. 


-93 - 

































Table 19: Alternative Scoring Summary 


Benefits 

Alternative 

Primitive 

Current 

Advanced 

Future 

Metric 

Weighting factor 

Best 

Threshold value 

Objective value 

Raw 

Rank 

Weighted Rank 

Raw 

Rank 

Weighted Rank 

Raw 

Rank 

Weighted Rank 

Raw 

Rank 

Weighted Rank 

Weight 

pounds 

20 

less 

lOlbs 

5lbs 

13 

3 

6.7 

13.8 

4 

5.0 

12.6 

2 

10.0 

5.7 

1 

20.0 

Battery life 

hours 

15 

longer 

6hr 

8hr 

4.5 

1 

3.0 

4.5 

3 

5.0 

6 

2 

7.5 

8 

1 

15.0 

Ease of use 

1 though 7 
scale 

15 

more 

4 

7 

4.5 

4 

3.8 

5 

3 

5.0 

6 

2 

7.5 

7 

1 

15.0 

Reliability - MTBF 

% 

15 

more 

90 

99 

96.19 

3 

5.0 

96.39 

2 

7.5 

96.26 

2 

7.5 

99.48 

1 

15.0 

Workload 

workload 

units 

15 

less 



20 

4 

3.8 

14.5 

3 

5.0 

8.5 

2 

7.5 

6.5 

1 

15.0 

Incoming message 
process 

% 

10 

more 

1# 

2# 

45 

1 

10.0 

45 

1 

10.0 

45 

1 

10.0 

45 

1 

10.0 

Outgoing message 
process 

% 

10 

more 

1# 

2# 

19 

2 

5.0 

30 

1 

10.0 

30 

1 

10.0 

30 

1 

10.0 

Total Score 

100 

37.2 

47.5 

60.0 

100.0 

Cost ($)K 

$2.7 

$2.9 

$2.7 

$105.7 

Bang per Buck 

13.8 

16.4 

22.2 

0.9 
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Capability Score versus Cost 
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Figure 36: Capability vs. Cost (“Bang for the Buck”) 
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V CONCLUSIONS AND RECOMMENDATIONS 


The Team Marine System Engineering team effectively applied the practices, 
processes, and analysis of the System Engineering Design Process (SEDP) in order to 
understand the needs of the customer. The team considered non material or DOTLPF 
alternatives. Non-material alternatives were not considered to be viable to solve the 
capability problem. Four (4) possible material alternative solutions were developed to 
meet the customer requirements. These four alternative solutions were derived from the 
Functional Architecture, Physical Architecture, and Operational Architecture. 

Through feasibility screening, modeling and simulation, decision scoring, risk 
analysis and cost analysis the team determined that an evolutionary development effort 
would be the best course of action for MCSC to undertake. In the near-term, the team 
recommends pursing the Advanced Alternative. This alternative is the best, “bang for the 
buck” integrated solution. As systems mature and technologies become available the 
team anticipates that MCSC will be able to evolve into the Future Alternative. Currently, 
the future alternative is not ready for production and is in the Concept Development 
Phase (DoD acquisition cycle). 

The team recommends that PM MERS continue the acquisition and development 
of the Advanced Alternative, migration to the Future Alternative, and consider the 
following: 

■ Conduct a Life Cycle cost estimate for the Advance approach to determine 
logistics support; 

■ Conduct a Human Factors study for current fielded Squad Leader 
communications in order to identify shortfalls in capability and to address 
these shortfalls in the next generation communication system; 

■ Include the results of this team’s effort as the foundation for future 
analysis and development. 
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APPENDIX A 


A PROJECT TEAM AND STRUCTURE 
1. Team Structure 

Team Marine consisted of 10 members, as seen in Figure 37 below,each with 
various educational backgrounds and systems engineering experiences. The team 
nominated Mr. Larry Bochenek and Mr. Jeff Dixon as the Project Lead and Co-Lead 
respectively. 


Lawrence 
Bochenek, 
Project Lead 


Jeffery Dixon, 
Project Co-Lead 


r i i i i i 


K rural Richard Kathryn ■ Yancy p@t@r Jonathan Brenda ■ Brian 

Amin Elgart H Hunt H Jeleniewski H Manternach H Reap Roach H Song 


Figure 37: Team Marine Members 

Each member was assigned tasking or volunteered to work on specific elements 
of the project. Some efforts were executed as individuals and many others were executed 
as teams, as seen below in Figure 38: Team Marine Functional Area Teams. 
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Figure 38: Team Marine Functional Area Teams 

Figure 38 shows how the team divided the efforts into functional areas and 
worked as an Integrated Product Team (IPT). 

IPT meetings and collaboration sessions were established to meet program 
objectives within each program phase. As an IPT completed the assigned tasking the IPT 
lead reported to the Project lead the status, and members were then reassigned as 
necessary. 
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APPENDIX B 


B PROJECT RISK MANAGEMENT 

1. Risk Management Analysis 

The goal of the Team Marine Risk Management Program is to implement 
methods and alternatives that keep overall program risk low. To accomplish this goal, 
Team Marine uses a centrally managed and executed risk strategy. The risk strategy is to 
identify potential risk items and events as early as possible, develop mitigation 
alternatives or handling options and reduce the potential impacts before the items cause 
serious cost, schedule and/or performance problems. The entire team participates in the 
Risk Management Board. This method is a proactive process to detect and mitigate risk 
elements. There are many elements of risk such as Programmatic, Cost, Schedule, 
Quality, Time, Human Resources, Communication, Performance as well as 
Organizational. (Wideman, 1992). For the purposes of this report, only performance risks 
will be evaluated. 

By definition, risk is defined as an event whose occurrence could jeopardize the 
successful completion of the project. Risk is the measure of the potential future inability 
to achieve project objectives within defined cost, schedule and performance constraints 
Project risks are thus identified and accessed for the probability of occurrence and its 
impact on successful completion of the project. 

2. Risk Management Process 

Risk management process will utilize two key factors to manage risk. The two 
key factors are probability/likeliness of occurrence and consequence of occurrence. The 
probability of occurrence is defined in terms of percentage values with respect to 
schedule and performance. The levels of likelihood of an occurrence are directly related 
to the probability of occurrence and are further defined in Table 20. 

Table 20: Likelihood of Occurrence levels 


Probability/Likelihood of Occurrence - Performance 

Level 

Probability of Occurrence 

Definition 

1 

0.0 <P <0.3 

Low likelihood 
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2 

0.3 <P <0.5 

Low to medium likelihood 

3 

0.5 <P <0.7 

Medium likelihood 

4 

0.7 <P <0.9 

Medium to high likelihood 

5 

0.9 <P< 1.0 

High likelihood 


The consequence of occurrence is the impact on successful completion of the 
project. The consequence of occurrence is defined in terms of percentage values with 
respect to schedule and performance. The specific ‘Consequence of Occurrence’ levels 
are directly related to percentile impacts and are further defined in Table 21. 


Table 21: Consequence of Occurrence levels 


Consequence of Occurrence - Performance 

Level 

Consequence of Failure 

Definition 

1 

0% < C < 10% 

Minimal impact 

2 

10% < C < 20% 

Minimum to medium impact 

3 

20% < C < 30% 

Medium impact 

4 

30% < C < 40% 

Medium to Major impact 

5 

C > 40% 

Major impact 


Based on probability and consequence distribution as stated above, team marine 
will use the following four step risk management approach. 

a. Step 1: Risk Identification 

The purpose of risk identification is to identify risk and evaluate its relative 
severity. The evaluation of risk identification is based on scale ranging from 1 to 5. A 
rating of 1 is implies lowest severity and a rating a 5 implies highest severity. The end 
result of risk identification is risk mapping matrix value of probability of particular 
failure with respect to consequence of that particular failure. The risk value will be 
identified in the form of a risk cube in risk tracking and control phase (step 4), where 
several project risks could be identified. 

b. Step 2: Risk Assessment 

Risk is assessed based on likelihood of occurrence and severity of the 
consequences to the overall project. The risk assessment is a calculated Expected 
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Consequence value. Risk is calculated as a product of probability of failure and 
consequence of failure. 

Expected Consequence (EC) = Probability of failure (Pf) * Consequence of failure (Cf) 

c. Step 3: Risk Mitigation 

Once the risk has been accessed, the following options can be exercised to handle 
the specific project risks: 

■ Accept the risk and do nothing more 

■ Mitigate the risk by expending team resources to reduce likelihood and/or 
severity 

■ Transfer the risk by an agreement with another party to eliminate likelihood 
and/or severity 

■ Deal with the risk as it occurs 


d. Step 4: Risk Tracking and Control 

Risk tracking will be accomplished by a risk mapping matrix to simplify and 
illuminate the risk management process and status. The graphical representation of risk 
mapping matrix is shown below in Figure 39. 



Consequence of Failure 
Figure 39: Generic Risk Mapping Matrix 


All risk items pertaining to the project are identified, with higher risk items 
prioritized over lower risk items. 

3. Program Risks 

a. Risk #1: Not improving communications capability 
Risk Identification: The team has identified recommending an unimproved 
communications capability as a risk. The risk is identified as a result of the identification 
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of the primitive alternative. If through our analysis we determine that the primitive 
alternative is our recommendation, we will have failed to provide the stakeholders with 
their requested capabilities. 

Risk Assessment: The risk assessment for not recommending an improved 
communications capability was identified as a minor risk with a rating of level 3. The 
levels of probability and consequence with respect to performance are calculated below: 
Probability/Likelihood of occurrence with respect to performance = P = 0.3 = Level 2 
Consequence of occurrence with respect to performance = C = 40% = Level 5 

Therefore, using Expected Consequence criteria, we calculated the following 
EC with respect to performance = 0.3*0.40 = 0.33 = 12% = Level 2 

According to the EC criteria, the consequence impact is of a minimum to medium 
level in terms of performance. 

Risk Mitigation: The consequence of risk with respect to performance being low, 
the team unanimously agreed to accept the risk and do nothing more, because the SE 
process employed was expected to prevent the occurrence of recommending an 
unimproved communications capability. 

Risk Tracking and Control: Figure 40 represents the tracking and control of Risk 

# 1 . 
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Consequence of Failure 


Figure 40: Risk #1 Mapping 
b. Risk #2: Increasing weight beyond acceptable range 
Risk Identification: Each of the alternatives beyond the primitive requires an 
increase or modification in components which could result in an increase in weight 
beyond the acceptable range. One of the goals of this project is to minimize the weight of 
the system. The severity of the risk is rated at 4 on a scale of 5. 

Risk Assessment: The probability and consequence of increasing the system 
weight beyond the acceptable range was identified as an elevated risk with a rating level 
of 4. The levels of probability and consequence with respect to performance are 
calculated below: 

Probability/Likelihood of occurrence with respect to performance = P = .8 = Level 4 
Consequence of occurrence with respect to performance = C = 70% = Level 5 
Therefore using Expected Consequence criteria, we get the following 
EC with respect to performance = 0.8 * 0.7 = 0.56 = 56% = Level 5 

According to the EC criteria, the consequence is at the maximum level in terms of 
performance. 

Risk Mitigation: Since the consequence of the risk with respect to performance is 
at the highest level, the team unanimously agreed to mitigate the risk by first determining 
the acceptable weight range. Secondly, the team assigned the greatest weighting factor to 
system weight. As a result of the mitigation plan, the revised values for 


- 109 - 














probability/likelihood of occurrence and consequence of occurrence with respect to 
performance were re-calculated below: 

Probability/Likelihood of occurrence with respect to performance = P = 0.2 = Level 1 
Consequence of occurrence with respect to performance = C = 5% = Level 5 
Therefore using Expected Consequence criteria, we get the following 
EC with respect to performance = 0.2 *0.05 = 0.01 = 1% = Level 1 

The mitigation provided the team with a revised EC value for performance which 
was reduced from 56% to 1%. 

Risk Tracking and Control: Figure 41 is the mapping matrix for Risk #2 and 
represents the tracking and control of risk before and after the mitigation. 

5 
4 
3 
2 
1 

1 2 3 4 5 

Consequence of Failure 

Figure 41: Risk #2 Mapping 

Figure 41, Risk #2 was mitigated to a much more controllable and 

acceptable level. 

c. Risk #3: Recommending a solution that is too complicated 
Risk Identification: Certain of the alternatives contain highly technical 
components such as the heads up display, piezoelectric power, and touch pad computers. 
These components may require much more training and higher order thinking than that 
required by the current system. The severity of the risk is rated at 4 on a scale of 5. 

Risk Assessment: The probability and consequence of Risk #3, (recommending a 
solution that is too complicated), has a definite impact on the project. The levels of 
probability and consequence with respect to performance are calculated below: 
Probability/Likelihood of occurrence with respect to performance = P = 0.8 = Level 4 
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Consequence of occurrence with respect to performance = C = 40% = Level 4 
Therefore using Expected Consequence criteria, we get the following 
EC with respect to performance = 0.8 *0.4= 0.36 = 36% = Level 4 

According to EC criteria, the consequence is at a medium to major level in terms 
of performance. 

Risk Mitigation: Since the consequence of risk with respect to performance is at a 
medium to major level, the team unanimously agreed to mitigate the risk by evaluating 
the ease of use of the systems. As a result of the mitigation plan, the team was able to 
manage and revise the risk assessment. Both the probability/likelihood of occurrence and 
consequence of occurrence were recalculated based on the mitigation with the revised 
values below: 

Probability/Likelihood of occurrence with respect to performance = P = 0.3 = Level 2 
Consequence of occurrence with respect to performance = C = 40% = Level 4 
Therefore using Expected Consequence criteria, we get the following: 

EC with respect to performance = 0.3 *0.4 = 0.12 = 12%o = Level 2 

Therefore the revised EC values for performance are reduced from 36% to 12% 
and thus lowering the consequence from major to medium to medium to minimal level. 

Risk Tracking and Control: Figure 42 represents the tracking and control of Risk 
#3 before and after the mitigation. This represents a risk that is more acceptable to adopt. 



Consequence of Failure 
Figure 42: Risk #3 Mapping 
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d. Risk #4: Technology Maturation 

Risk Identification: The technology maturation for some components included in 
the Future Alternative is below standard. A capability that is non-existent is rated at a 
scale of 4 out of 5, both in terms of probability and consequence. 

Risk Assessment: The probability and consequence of non-existent solutions and 
architectures could have major impacts in addressing objectives and effective needs of 
the system. The levels of probability and consequence with respect to performance are 
calculated below: 

Probability/Likelihood of occurrence with respect to performance = P = 1.0 = Level 4 
Consequence of occurrence with respect to performance = C = 90 % = Level 5 
Therefore using Expected Consequence criteria, results in the following. 

EC with respect to performance = 1.0 *0.9 = 0.9 = 90 % = Level 5 

According to EC criteria, the consequence impact is of medium to major level in 
terms of performance. 

Risk Mitigation: Since the consequence of this risk is high with respect to 
performance, the team unanimously agreed to mitigate risk by attaching a large cost to 
the undeveloped technology. 

As a result of the mitigation to technology maturation the following risk 
parameter was revised for probability/likelihood of occurrence. 

Probability/Likelihood of occurrence with respect to performance = P = 0.3 = Level 1 
Therefore using Expected Consequence criteria, we get the following 
EC with respect to performance = 0.3 * 1.0 = 0.30 = 30% = Level 4 

Therefore the revised EC values for performance are reduced from 90% to 30% 
and thus lowering the consequence from the High level to the Medium to Major level. 

Risk Tracking and Control: The following risk mapping matrix represents the 
tracking and control of risk before and after the mitigation. 
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Consequence of Failure 
Figure 43: Risk #4 Mapping 
4. Project Risk Status 

Table 22 summarizes the overall project risks post risk mitigation efforts. 


Table 22: Project Risk Summary 


RISK ID 

Likelihood 

Consequence 

R1 

Level 2 

Level 2 

R2 

Level 1 

Level 5 

R3 

Level 2 

Level 2 

R4 

Level 1 

Level 4 


Figure 44 below, provides an overall graphical representation of all identified 
project risks in a single risk mapping matrix. 
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Figure 44: Mapped Project Risks 
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APPENDIX C 


C MARINE EXPEDITIONARY RIFLE SQUAD (MERS) ARCHITECTURE VIEWS 


Table 23: Operational Information Exchange Matrix (OV-3) 


Architecture 

View 

Needlin 

e ID 

Sending 

Node 

Sending 

Hierarch 

9 ID 

Sending Activity 

Information Exchange (IE) 

Receiving 

Node 

Receivin 

g 

Hierarch 

Receiving Activity 

Critical! 
l| Code 

Criticalit 

9 

Informa 

tion 

Tjpe 

Classificati 

on Level 

MERS Combat 
Operations 

ML 4 

PLT Cmdr 


EKternal 

Commander Guidance 

Squad Ldr 

A1.1 

Assign Mission 

1 

Yes 

Voice 

Secure 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A1.2 

Determin Mission Profile 

SMEAC Brief 

Fire Team 

A1.3 

Brief the Squad 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A1.3 

Brief the Squad 

SMEAC detail request 

Fire Team 

A1.3 

Brief the Squad 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A1.3 

Brief the Squad 

Mission Provision Requirement 

Fire Team 

A1.4 

Provision the Squad 

2 

Yes 

Voice/dat 

a 

Unclassified 

MERS Combat 
Operations 

MLS 

Fire Team 

A1.4 

Provision the Squad 

Fire Team Provision Status Report 

Squad Ldr 

A1.4 

Provision the Squad 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

ML 4 

Squad Ldr 

A1.4 

Provision the Squad 

Squad Provision Status Report 

PLT Cmdr 


External 

2 

Yes 

Voice/dat 

a 

Secure 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A2.1 

Execute Route 

Command to execute Squad 
mission 

Fire Team 

A2.1 

Execute Route 

2 

Yes 

Voice/dat 

a 

Unclassified 

MERS Combat 
Operations 

MLS 

Fire Team 

A2.1 

Execute Route 

Position Location Information 

Squad Ldr 

A2.2 

Provide PLI Updates 

3 

Yes 

Data 

Unclassified 

MERS Combat 
Operations 

ML 5 

Fire Team 

A2.1 

Execute Route 

Position Location Information 

Coalition 

Forces 


External 

3 

Yes 

Data 

Unclassified 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A2.2 

Provide PLI Updates 

Tactical Commands 

Fire Team 

A2.3 

Coordinate Tactical 
Maneuvers 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

ML 4 

Squad Ldr 

A2.2 

Provide PLI Updates 

Position Location Information 

PLT Cmdr 


External 

2 

Yes 

Data 

Secure 

MERS Combat 
Operations 

MLS 

Fire Team 

A2.3 

Coordinate Tactical 

Maneuvers 

Tactical Situation 

Squad Ldr 

A2.3 

Coordinate Tactical 
Maneuvers 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Fire Team 

A2.3 

Coordinate Tactical 

Maneuvers 

Tactical Situation 

Squad Ldr 

A2.4 

Implement Force 
Protection Measures 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A2.4 

Implement Force Protection 
Measures 

Command to Fire 

Fire Team 

A3.1 

Employ Veapons 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Fire Team 

A3.1 

Employ Veapons 

Fire Fight Status 

Squad Ldr 

A3.2 

Coordinate Fire Support 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

MLS 

Squad Ldr 

A3.2 

Coordinate Fire Support 

Fire Support Request 

Fire Team 

A3.3 

Assault Enemy Position 

2 

Yes 

Voice/dat 

a 

Secure 

MERS Combat 
Operations 

ML 2 

Squad Ldr 

A3.2 

Coordinate Fire Support 

Fire Support Request 

FSCC 


External 

2 

Yes 

Voice/dat 

a 

Secure 
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Table 24: Operational Information Exchange Matrix (OV-3) (cont.) 


Architecture 

Viev 

Needlin 
e ID 

Sending 

Node 

Sending 

Hierarch 

9 ID 

Sending Activitg 

Information Exchange (IE) 

Receiving 

Node 

Receivin 

g 

Hierarch 

Receiving Aclivitg 

Critical! 
tg Code 

Critical!! 

9 

Informa 

tion 

Tjpe 

Classificati 
on Level 

MERS Combat 
Operations 

NLS 

Fire Team 

A3.3 

Assault Enemy Position 

Fire Fight Status 

Squad Ldr 

A4.1 

Secure Perimeter 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

NLS 

Squad Ldr 

A3.3 

Assault Enemy Position 

Terminal Veapons Guidance 

Fire Team 

A4.1 

Secure Perimeter 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 7 

Squad Ldr 

A3.3 

Assault Enemy Position 

Terminal Veapons Guidance 

Airborne 

Assets 


External 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 3 

Squad Ldr 

A3.3 

Assault Enemy Position 

Terminal Veapons Guidance 

Mech-Armor 

Support 


External 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 1 

Squad Ldr 

A3.3 

Assault Enemy Position 

Terminal Veapons Guidance 

NSFS Group 


External 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 2 

Squad Ldr 

A3.3 

Assault Enemy Position 

Terminal Veapons Guidance 

FSCC 


External 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NLS 

Squad Ldr 

A4.1 

Secure Perimeter 

Causality Status Request 

Fire Team 

A4.2 

Assess Casualties 

5 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

NLS 

Fire Team 

A4.1 

Secure Perimeter 

Ammunition Resupply Request 

Squad Ldr 

A4.3 

Resupply Ammunition 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

NLS 

Fire Team 

A4.2 

Assess Casualties 

Casualtity Report 

Squad Ldr 

A4.2 

Assess Casualties 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

NLS 

Fire Team 

A4.2 

Assess Casualties 

Status of Fire Team 

Squad Ldr 

A4.4 

Convey Situational 

Status 

2 

Yes 

Voice 

Unclassified 

MERS Combat 
Operations 

NLS 

Squad Ldr 

A4.2 

Assess Casualties 

MEDEVAC Request 

Medical 

Support 


External 

2 

Yes 

Data 

Secure 

MERS Combat 
Operations 

NLS 

Fire Team 

A4.3 

Resupply Ammunition 

Fire Team Provision Status Report 

Squad Ldr 

A4.4 

Convey Situational 

Status 





MERS Combat 
Operations 

NL 4 

Squad Ldr 

A4.4 

Convey Situational Status 

SITREP 

PLT Cmdr 


External 

1 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 4 

PLT Cmdr 


External 

Commander Guidance 

Squad Ldr 

A2.1 

Execute Route 

1 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 2 

FSCC 


External 

Fire Support Response 

Squad Ldr 

A3.3 

Assault Enemy Position 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 7 

Airborne 

Assets 


External 

Fire Notification 

Squad Ldr 

A4.1 

Secure Perimeter 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NLS 

Mech- 

Armor 


External 

Fire Notification 

Squad Ldr 

A4.1 

Secure Perimeter 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 1 

NSFS 

Group 


External 

Fire Notification 

Squad Ldr 

A4.1 

Secure Perimeter 

2 

Yes 

Voice/Dat 

a 

Secure 

MERS Combat 
Operations 

NL 2 

FSCC 


External 

Fire Notification 

Squad Ldr 

A4.1 

Secure Perimeter 

2 

Yes 

Voice/Dat 

a 

Secure 
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Figure 45: MERS OV-5 Context Diagram 
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Figure 46: MERS OV-5 Operational Activity Model 
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Cmdr Guidance - 

(Patrol Route, 

Intelligence Reports, 
Weather Reports, orders to 
execute mission, etc.) 
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Figure 47: MERS OV-5 Operational Activity Model A1 
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Figure 48: MERS OV-5 Operational Activity Model A2 
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Figure 49: MERS OV-5 Operational Activity Model A3 
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Figure 50: MERS OV-5 Operational Activity Model A3 
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APPENDIX D 


D RIFLE SQUAD COMMUNICATIONS SYSTEM STAKEHOLDER 

QUESTIONNAIRE 

Team Marine categorized Stakeholders in three categories: 

• Sponsors/Decision makers 

• Clients/end users 

• Analysts/Evaluators 

Questions for Sponsors/Decision makers included: 

• Can a new system be developed and integrated into the Marine Squad? 

• Can an "off the shelf' system be used? 

• What is the schedule? 

• What is the cost? 

• Is there funding? 

• Can an existing program be used? 

• When is the system needed? 

• What Tactics, Techniques, Procedures need to be added or revised? 

Questions for the Clients/end users 

• What are your requirements? 

• What are your training requirements? 

• Will the system interface with other systems? 

• What are the systems, interfaces, and information requirements? 

• What information is needed? And who needs it and when? 

• What are the skill levels of the members in the squad? 

• What types of systems are employed today? What are the "goods" and the bads? 

• What capabilities will be fielded soon within the next 12-24 months? 

Questions for the Analysts/Evaluators: 

• What kind of testing is required? 

• What measures will be used? 

• Are there Human system interface issues? 
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APPENDIX E 


E COMMUNICATIONS SYSTEM ARCHITECTURE 


PLT Commander Guidance _ 

PLT Geographic position _ 

PLT Mission Objectives / FRAGO 

PLT Fire Control Plan _ 

PLT Friendly/enemy location 


AJS Friendly/enemy location 
AJS Mission Objectives 

AJS Geographic position 

ACS Geographic position 

ACS Friendly/enemy location 

AMCS Geographic position 

AMCS Mission Objectives 

AMCS Friendly/enemy location 


FSCC Fire Support Response 
Airborne Fire Notification _ 

Mech-Armor Fire Notification 
NSFS Fire Notification 
FSCC Fire Notification 


Process Squad 
Leader 

Communication / 
Information 


A1 —| 


SQD Geographic Position 


SQD Friendly Locations 


SQD Members health 


SQD Provision Status Report 


SQD CASEVAC 


SQD Fire Support Request 


SQD Geographic Position 


SQD Enemy Locations 


SQD Mission Objectives /Frago 


SQD Situation Update 


SQD Terminal Weapons Guidance — Airborne Assets _ 

SQD Terminal Weapons Guidance - Mech-Armor Support 

SQD Terminal Weapons Guidance — NSFS Group 
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Figure 51: Squad Communication System Operational View AO 
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Figure 52: Squad Communication System Operational View A1 
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Figure 53: Squad Communication System Operational View A2 
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Figure 54: Squad Communication System Operational View A22 
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Figure 55: Squad Communication System Operational View A23 
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Figure 56: Squad Communication System Operational View A24 
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Figure 57: Squad Communication System Functional View A-l 
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Figure 58: Squad Communication System Functional View AO 
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Figure 59: Squad Communication System Functional View A1 
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Figure 60: Squad Communication System Functional View A2 
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Figure 61: Squad Communication System Functional View A3 
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Figure 62: Squad Communication System Functional View A4 
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Figure 64: Squad Communication System Functional View A6 
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Figure 65: Squad Communication System Physical View 
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APPENDIX G 


G ACRONYM LIST 


ACE 

Aviation Command Element 

BFT 

Blue Force Tracker 

C2 

Command and Control 

C4 

Command, Control, Communications and Computers 

CDD 

Capabilities Development Document 

COA 

Course of Action 

COC 

Combat Operations Center 

CPU 

Computer Processing Unit 

CTP 

Common Tactical Picture 

CUI 

Controlled Unclassified Information 

DC-SIAT 

Deputy Commander, Systems Engineering, 

Interoperability, Architectures and Technology 

DODAF 

Department of Defense Architectural Framework 

DOTMLPF 

Doctrine Organization Training Materiel Leadership 
Personnel and Facilities 

ECO 

Enhanced Company Operations 

FOC 

Full Operational Capability 

FRAGORDS 

Fragmentation Orders 

GCE 

Ground Command Element 

GPS 

Global Positioning System 

GSE 

Ground Soldier Ensemble 

HQMC 

Headquarters Marine Corps 

ICD 

Initial Capability Document 

IDEF 

Integration Definition for Function Modeling 

IISR 

Interim Intra-Squad Radio 

IOC 

Initial Operational Capability 

IT 

Information Technology 

JFCOM 

Joint Forces Command 

JITC 

Joint Integrated Test Center 

JPO 

Joint Program Office 

JROCM 

Joint Requirements Oversight Counsel Memorandum 

JTRS 

Joint Tactical Radio System 

LCE 

Logistics Command Element 

MAGTF 

Marine Air-Ground Task Force 

MCCDC 

Marine Corps Combat Development Command 

MCOTEA 

Marine Corps Operational Test & Evaluation Activity 

MCSC 

Marine Corps Systems Command 

MCWL 

Marine Corps War-fighting Laboratory 

MEF 

MAGTF Expeditionary Force 

MERS 

Marine Corps Expeditionary Rifle Squad 

MOE 

Measures of Effectiveness 
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MSSE 

Master of Science in Systems Engineering 

MTBF 

Mean Time Between Failure 

NPS 

Naval Postgraduate School 

NS A 

National Security Agency 

OPORDS 

Operational Orders 

OV 

Operational View 

PDA 

Personal Digital Assistants 

PLI 

Position, Location Information 

PM-MERS 

Program Manager for Marine Expeditionary Rifle Squad 

POM 

Program Objective Memorandum 

POR 

Program of Record 

RR 

Rifleman Radio 

SA 

Situational Awareness 

SATCOM 

Satellite Communication 

SE 

Systems Engineering 

SEDP 

Systems Engineering Design Process 

SME 

Subject Matter Expert 

HP 

Tactics, Techniques and Procedures 

USB 

Universal Serial Bus 

USMC 

United States Marine Corps 

WARNORDS 

Warning Orders 
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